On Sun, Nov 23, 2025, at 17:00, Tim Düsterhus wrote: > Hi > > On 11/10/25 20:19, Rob Landers wrote: > > Updated RFC: > > https://wiki.php.net/rfc/namespace_visibility > > <https://wiki.php.net/rfc/namespace_visibility?utm_source=chatgpt.com> > > From the RFC I'm seeing that it's legal to redefine methods in > different namespaces? I've only figured that out with the last example > in the “Preventing Visibility Reduction and Incompatible Redeclaration” > section, it might have been hinted at with “However, visibility is > enforced based on the namespace where they were declared, not on the > inheritance hierarchy:” but if it did, I didn't understand it.
No, it should be illegal, but it looks like the current RFC text doesn’t say that. Basically, private(namespace) is incompatible with private(namespace) if the original namespace doesn’t match the current namespace. I’ll update the RFC later this week. > I feel that namespace-scoping needs to be restricted to top-level > symbols to be easy to reason about. This also brings me to the next > point: What about free-standing functions and constants? > public/protected/private doesn't make sense for them, since they are not > part of a inheritance hierarchy. But namespace-scope would be meaningful. That would need https://github.com/php/php-src/pull/20490 (subtle wink emoji) > > All in all, I feel that file-private symbols would solve many of the > same problems, but be much easier to reason about. The SessionManager > from your example could just be file-private. You can use private(namespace) as effectively file-private, just use a namespace in a single file. And, if you need to refactor, you don’t need to be constrained to a single file. — Rob
