On 29 April 2025 19:50:52 BST, "Tim Düsterhus" <[email protected]> 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]