On 29 April 2025 19:50:52 BST, "Tim Düsterhus" <t...@bastelstu.be> wrote:
>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.
I think you are insisting on a different definition of "private" for nested
classes than exists anywhere else in the language, and one that I've not seen
evidence of in any other similar language either. It seems you want members to
be "hidden", such that you can't even know they exist.
More specifically, you want their *fully-qualified name* to somehow be
available for reuse. That's not how private members of a class work - methods
A::foo() and B::foo() have different fully-qualified names, as do properties
A::$foo and B::$foo, regardless of visibility and inheritance. It's not how
"namespace private", "module private", or "file private" classes would
naturally work, because they all would need to be referenceable with
fully-qualified names within the scope where they were visible.
It's also not a new problem: PHP doesn't enforce a file and directory layout,
and libraries can and do define things "inside" each other's namespaces. When
declaring a class, you have to be aware of whether a class with the same
fully-qualified name has been, or will be, declared in another file.
There is a challenge in any feature that encourages multiple definitions in one
file, that new conventions are needed to know at a glance when that is in use,
because we have become accustomed to the (Java-inspired?) one-class-per-file
convention. That's not about *hiding* things, though, because those multiple
definitions might be public; nor is it unique to this proposal - it comes up
with function autoloading, typedefs, and many more.
>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`.
The value-add is 1) that they enforce the visibility at the language level, and
2) that they allow a concise syntax for declaring a set of closely related
classes.
I'm not wholly convinced that they do that better than "file private" or
"module private", but I don't agree that "class hiding" is essential, or even
particularly desirable.
Rowan Tommins
[IMSoP]
