On Sat, Mar 15, 2025, at 12:53, Rowan Tommins [IMSoP] wrote:
>
>
> On 14 March 2025 23:37:08 GMT, Rob Landers <[email protected]> wrote:
> >I could get behind ::, but I feel that it introduces human ambiguity. I
> >don't believe it would introduce compiler ambiguity, but as a human, I have to hope the
> >programmers are using a style that makes it obvious what are inner classes and what are
> >constants/methods.
>
> As far as I can see, all four languages I looked up last night (Java, C#, Swift, Kotlin) use
> the same syntax for accessing a nested type as for accessing a property or method, so we'd be
> following the crowd to use "::"
>
> That said, I think they all also use that same syntax for namespace (or equivalent) lookups, so
> the same argument can be made for "\". (Why PHP separates those isn't entirely clear
> to me.)
>
> Having some new syntax makes them feel more "exotic" to me. The C# and Swift docs
> give the impression that nesting types is "just something that can happen", rather than a
> whole new language concept to learn.
>
> Java's "inner classes" are something different, and I think we should avoid
> using that term.
>
>
>
> > Furthermore, I'm relatively certain this approach can be slightly modified to support
> > "namespace private/protected" classes, in general. So, that will also possibly be a
> > follow-up RFC and having them mixed up will complicate things. In any case, I am not a fan of using
> > the namespace separator here.
>
> To me namespace, module, or file visibility seem like much more natural additions to the
> language, and to solve most of the same problems as nesting types.
>
> I guess a public nested class is a bit like a "friend class"? In that it has special
> access to its surrounding class, but otherwise might as well just be sharing a namespace with it.
> But it's also necessarily in the same file, so marking those members "file private"
> rather than "private" would also allow that.
>
> A private nested class can only be explicitly mentioned within that narrow context, which again
> feels very much equivalent to "file private".
>
>
> > $user = new
> > User:>Builder("Rob")->withEmail("[email protected]")->build();
> >
> > The user builder is intrinsically tied to the User class itself, it isn't just a
> > namespace. The user builder shares scope with the user class and is able to be the only way to
> > construct a user (barring reflection).
>
> If we had either file or namespace visibility, exactly the same thing could be achieved with
> those, and would look like this:
>
> $user = new
> User\Builder("Rob")->withEmail("[email protected]")->build();
>
> The "User" class would have a "file private" or "namespace
> private" constructor, callable from the "User\Builder" class but not elsewhere; the
> build() method would return the "User" instance.
>
>
>
> I think I'm coming to the conclusion that we should use backslash: nested types can be
> viewed as a shorthand way of having a class and namespace with the same name, plus applying some
> visibility rules to that namespace.
>
> Rowan Tommins
> [IMSoP]
>
I don’t think \ is viable. If we used slash it would complicate autoloading and be
impossible to differentiate between
namespace Outer;
class Inner {}
And
class Outer {
class Inner {}
}
These would both resolve to the same class name for Outer\Inner. Which one it resolves to would
depend on how you implement autoloading (which may be desirable for BC reasons). Then there becomes
the question of either letting user-land implement the autoloading changes, or have php walk
“up” the namespace chain in the hopes it implements an inner class.
So, maybe, it could be useful to use \ but in the long run, I’m not sure it makes
sense.
— Rob