On Thu, Apr 24, 2025, at 16:31, Tim Düsterhus wrote: > Hi > > On 4/20/25 15:43, Rob Landers wrote: > > As it seems that discussion has mostly died down, I'd like to put this > > towards a vote starting on May 1, 2025. > > Unfortunately I did not have the time to follow the discussion after > mid-March, so this might or might not have been discussed already. I > just skimmed the RFC and a big issue from my PoV is the interaction of > private nested classes and the shared namespace. > > All existing private symbols in PHP are “invisible” or “non-existent” > from the outside for all intents and purposes. As an example, it is > possible to add a new private method to a class, without having an > effect on child classes that already defined a method with the same name. > > To my understanding this is different with private nested classes. A > private nested class will “block the name” in the global class table, > leading to naming conflicts with something the user shouldn't even know > exists (because it's private). > > This is a reason for me to vote against the RFC and a reason why I > preferred Ilija's “file private” classes that are much simpler to reason > about. > > Best regards > Tim Düsterhus >
Thank you for your feedback! I think you would then have the problem that was pointed out by Levi the other day; where you would then have ambiguity. If you could have both private and public names in the same namespace, then you would end up not knowing which one was being referred to. Also, it is worth pointing out that private symbols are *not* "invisible" or "non-existent" from outside classes. They emit their own errors: https://3v4l.org/PEGeA that indicate you tried to access something you shouldn't be able to. This is different than when you try to access something that actually doesn't exist: https://3v4l.org/nWVPV — Rob
