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]