Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129156
Feedback-ID: id5114917:Fastmail
Message-ID: <72f90052-fa19-415c-9f5a-ae75275fd030@rwec.co.uk>
Date: Sat, 8 Nov 2025 21:20:03 +0000
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] RFC: Namespace-Scoped Visibility for Methods and
 Properties
Content-Language: en-GB
To: internals@lists.php.net
References: <e21b1992-d426-46cd-b86a-6d6a5844c934@app.fastmail.com>
 <f1f694d7-d494-45c5-a4e4-fb39809d3b67@rwec.co.uk>
 <c0bfa15e-1df2-4d87-8092-2531b2bafcb3@app.fastmail.com>
In-Reply-To: <c0bfa15e-1df2-4d87-8092-2531b2bafcb3@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 08/11/2025 20:08, Rob Landers wrote:
> 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?


While I appreciate the desire to keep things simple, I don't think we 
can avoid asking those questions, we can only propose answers. In your 
current RFC, the answers are:

- No two namespaces are related, even if their names imply a hierarchy.
- Two "internal" classes in the same namespace can see each other even 
if they are written by different vendors.


> 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.

I don't think that's true. The language already recognises the namespace 
separator, and that if you are in namespace "Acme\AuthLib", an 
unqualified reference to "Services\SessionManager" refers 
to "Acme\AuthLib\Services\SessionManager". That doesn't require any 
concept of "package", but it is clearly based on the conception of 
namespaces as a hierarchy.


> 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.

My concern is that by restricting it so much, we would prevent most of 
the real-world use cases for it, since the reality is that people use 
much more complex namespace hierarchies.


> 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.

I mentioned, briefly, two possibilities:

> I think we need a keyword or attribute which takes as a parameter 
> either the namespace prefix, or the number of levels to match

To spell those out, the prefix version could look like this:

namespace Acme\AuthLib\Somewhere\Deep\In\Package;
// ...
#[NamespacePrivate('Acme\AuthLib', includeChildren: true)]


A number of levels version could look like this:

namespace Acme\AuthLib\Somewhere\Deep\In\Package;
// ...
#[NamespacePrivate(minLevels: 2, maxLevels: null)]

There's all sorts of variations on how those arguments could be 
presented, keywords vs attributes, etc; but the key point is the 
language is not defining where the boundary is, it is requiring the user 
to do so.


The prefix-based approach could be expanded into an allow-list that 
didn't require any relationship to the current namespace at all:

  namespace Acme\AuthLib\Somewhere\Deep\In\Package;
// ...
#[AllowNamespace('Acme\AuthLib\*')]
#[AllowNamespace('Zeppo\FrameworkCore\*')]

Or even an allow-deny rule system:

#[AllowNamespace('Acme\AuthLib\*')]
#[DenyNamespace('Acme\AuthLib\Plugins\*')]

At that point, it's admittedly rather complex, but it makes *even fewer* 
assumptions about what constitutes a "package".


-- 
Rowan Tommins
[IMSoP]