Hi
On 4/24/25 21:26, Rob Landers wrote:
This was very deliberate after much feedback and careful design. People were
quite clear (including yourself, if I recall) that they didn't want a new
syntax. Since there is no new syntax, there is no way to tell (from the
outside) whether A\B\C refers to a nested class or an outer class. That's by
design and mirrors other languages and how they handle nested classes.
To clarify: I was not against new syntax per se. I was against “invented
syntax”. Double-backslash would have been new syntax, but reasonably
closely resemble the existing namespace separator. `::` would have also
worked for me, since the naming conflicts would have been limited to the
class itself.
If I am not mistaken about Java (it's been a while since I did Java, and
never professionally), there are two things that would prevent the
naming conflict there:
1. Package names are lowercase by convention. Thus if you have two
components with an uppercase first letter, then it's a nested class.
2. In the JVM bytecode, the names of nested classes are mangled to
incorporate the parent class' name.
(2) is also what is happening for private properties in PHP and that is
what prevents the conflicts.
I'm not sure what you are saying here. I mean, what you are saying is
self-evident but I don't understand how it applies to nested classes. You can
write the following without any issues:
class Foo {
private class Bar {}
}
class Bar extends Foo {
private class Bar extends Foo {}
}
And it will work just fine. You could even make the nested classes public if
you want to, or one of them private and one of them public. As mentioned in the
RFC, the nested class is bound to the lexical scope of the class it is written
in. So Foo\Bar and Bar\Bar are different classes altogether in the example
above.
I'm saying that I cannot add a private class Foo\Bar inside of the class
Foo without checking whether a class Bar inside a namespace Foo already
exists, since both would conflict. Even more problematic: I can't add a
class Bar inside of namespace Foo, without needing to check the source
code of class Foo to determine whether there is a private class Bar that
I have no business of knowing that it exists.
This is also not some hypothetical problem. I've more than once created
a namespace that matches a class name of the “parent namespace”. The PHP
core Random\Engine interface + the Random\Engine\* namespace would be
one example. Laminas Diactoros also has Laminas\Diactoros\Request as a
class and Laminas\Diactoros\Request\* as a namespace.
And when I'm forced to always verify whether my private classes conflict
with something, then nested classes do not provide a measurable
value-add over a “regular class” in a namespace matching the parent
class' class name that is marked `@internal`.
Best regards
Tim Düsterhus
