On Sat, Mar 15, 2025, at 12:53, Rowan Tommins [IMSoP] wrote:
>
>
> On 14 March 2025 23:37:08 GMT, Rob Landers <rob@bottled.codes> 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("rob@bottled.codes")->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("rob@bottled.codes")->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
