On Sun, May 4, 2025, at 15:52, Tim Düsterhus wrote:
> Hi
>
> On 4/30/25 12:51, Rowan Tommins [IMSoP] wrote:
> > 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.
>
> No, I don't think I'm using a different definition of "private" for
> nested classes.
>
> > 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.
> The difference is that for private class members there is no chance of
> name collisions of the "fully-qualified" name, but there is for nested
> classes as proposed in this RFC. There is no way for anyone except for
> the author of the class A to create a property with the fully
> qualified name A::$foo. Granted, properties could be inherited from a
> parent class and might thus cause collisions with a private property in
> a subclass. However the same collision would happen if the child class
> would already have a public property of the same name. Importantly, the
> child class could just rename its private property without any effect on
> any other class and also parent classes can introduce private properties
> without any effect on any other class.
>
> This is difference for nested classes as proposed in this RFC, since the
> namespace of nested classes is shared with the namespace of regular
> classes and the namespace of regular classes is not “closed off” for
> addition after the initial declaration.
>
> > 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.
>
> This is correct, but all these other classes that could conflict are
> part of the *public API* of a library. But now with private nested
> classes I would also be aware of the private part of a library to avoid
> conflicts.
>
> Best regards
> Tim Düsterhus
>
Hi Tim,
I think these are fundamental problems (if they are a problem at all) with how PHP currently does
namespaces and names. I'm curious if you would vote "no" for namespace visibility as
well? While not intended to be used as "modules," this has many of the same constraints
and effects that full namespace visibility would have—including the same problems you allude to
here.
As I was going to work on short syntax classes next if this one passed, as well as namespace
visibility/modules after that (regardless of this RFC passing), I'd really like to know if this
behavior is that big of an issue. If so, it is probably not worth pursuing namespace visibility if
this RFC fails.
For everyone else who voted "no"; I would sincerely love to know the reason. Even if you
just email me directly; it would really help me understand what can be improved in any future RFCs.
— Rob