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]
