On Sat, Nov 8, 2025, at 17:50, Rowan Tommins [IMSoP] wrote: > On 08/11/2025 12:43, Rob Landers wrote: > > I’d like to introduce an RFC for discussion: > > https://wiki.php.net/rfc/namespace_visibility which proposes a new > > visibility modifier: private(namespace). > > > Hi Rob, > > Thanks for putting together the RFC. > > My main concern with this and similar single-keyword proposals is that > its only useful if people lay out their code in a particular way, rather > than fitting with the variety of namespace hierarchies seen in the wild. > > For instance, in your example, you have two classes: > > - App\Auth\SessionManager > - App\Auth\SessionStore > > But if this was library with a set of interchangeable session stores, it > might well lay them out like this: > > - Acme\AuthLib\Session\Manager > - Acme\AuthLib\Session\Store\SessionStoreInterface > - Acme\AuthLib\Session\Store\DatabaseSessionStore > - Acme\AuthLib\Session\Store\FileSystemSessionStore > - etc > > In that case, "current namespace plus children" would work, and I'd be > interested in your reasoning for requiring an exact match instead. > > > But even that might not be enough, if for some reason it looked like this: > > - Acme\AuthLib\Services\SessionManager > - Acme\AuthLib\Implementations\SessionStore\SessionStoreInterface > - Acme\AuthLib\Implementations\SessionStore\DatabaseSessionStore > - Acme\AuthLib\Implementations\SessionStore\FileSystemSessionStore > - etc > > Here, what we want is visibilty for everything inside "Acme\AuthLib", > not only in "Acme\AuthLib\Services". > > Since, as you say in another reply, we don't have a standard definition > of "module", "package", or "assembly", I think we need a keyword or > attribute which takes as a parameter either the namespace prefix, or the > number of levels to match. > > > -- > Rowan Tommins > [IMSoP] >
Hi Rowan, Thanks for the detailed feedback. The exact-match requirement is intentional rather than incidental. In my nested classes RFC, I assumed namespaces behaved hierarchically, and it was pointed out that isn’t always guaranteed. So, one of the main design goals with this RFC was to make a boundary that was crisp and unsurprising: if two pieces of code have the same lexical namespace, access is allowed; if not, it isn’t. There's no need to consider namespace depth, prefixes, or directory layout. The moment we allow "namespace prefixes", we introduce questions that need to be fleshed out separately and with care. Do we treat "Acme\AuthLib\Session" and "Acme\AuthLib\Services" as related? Even if they come from different vendors and are unrelated in any way? Are namespaces hierarchical or just flat strings that happen to contain separators? Today namespaces are a name resolution mechanism, not a semantic hierarchy. Matching by prefix would start treating them as a package system, and I explicitly am trying to avoid that in this RFC. By restricting the rule to exact namespace equality, the feature is straightforward to explain and to understand. It also prevents "accidental" access because two unrelated namespaces happen to share a prefix. If we ever define a module/package boundary in PHP, a recursive or prefix-based visibility could be layered on top. For this RFC, I’m aiming for a feature that provides enforceable encapsulation using the boundaries PHP already defines, albeit, loosely through name resolution. If you have a concrete, unambiguous rule for prefix-based access that wouldn’t cause surprises or make assumptions about how people organise their codebases, I’d be happy to discuss it. Right now, every version I’ve explored would reopen the "module"/"package" debate from this summer. — Rob
