Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129158
Feedback-ID: id5114917:Fastmail
Message-ID: <2d9f8f1d-e568-4bb5-b30c-0a9e54a8f5fe@rwec.co.uk>
Date: Sat, 8 Nov 2025 23:13:17 +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>
 <72f90052-fa19-415c-9f5a-ae75275fd030@rwec.co.uk>
 <be5c97b7-430d-4d4e-b413-b331c85816e1@app.fastmail.com>
In-Reply-To: <be5c97b7-430d-4d4e-b413-b331c85816e1@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 21:56, Rob Landers wrote:

>
> Those approaches: prefix matching, wildcard matching, level-based 
> matching, or allow/deny lists are all significantly more expressive 
> than what this RFC is aiming for.


Yes. That's why I think they're a better idea.


> They move the discussion from "namespace -private visibility" into 
> designing a generalised access-control system or a de-facto package model.


No. They explicitly *avoid* defining any kind of package model, by 
letting the user mention *whatever prefix they like*. That might match 
the root namespace they mention in composer.json, but it might just be a 
particular set of classes in a giant spaghetti application with no 
conception of "package" whatsoever.


> The goal of this RFC is intentionally minimal: take the boundary that 
> already exists in the language (the lexical namespace)


 From the language's point of view, "namespace Foo\Bar; $x = new Baz;" 
is interchangeable with "namespace Foo; $x = new Bar\Baz;"

Namespaces are inherently hierarchical, and *any* cut-off point in that 
hierarchy is an equally natural boundary.


> Exact namespace equality keeps the rule unambiguous


What is ambiguous about any of the examples I showed?


> requires no new access-control model


I have no idea what you mean by this. We don't currently have any 
namespace-based access-control, and we're addding it. How does "must 
match exactly" vs "must match given prefix" change that?


> avoids assumptions about how developers structure hierarchies


On the contrary, it assumes that a developer will structure their 
hierarchy so that related classes are in the same namespace, and not any 
parent or child namespaces.

My suggestion, on the other hand, truly makes no assumption: it lets the 
developer specify exactly the structure they want.


> One advantage of keeping this RFC small is that it can be expanded 
> later without a BC break. For example, prefix matching (maybe 
> something like `private(namespace: Acme\AuthLib)`) or a 
> protected-namespace variant could be layered on top if the community 
> wants to go in that direction.

That's a reasonable argument, but the risk is that if we don't consider 
what that future scope would look like, we can end up with syntax or 
semantics that makes our lives unnecessarily difficult later. As I 
understand it, this happened to some extent with the "readonly" keyword.


> This RFC isn’t intended to solve the entire space; it’s the smallest 
> useful step that seems to fairly cleanly fit into PHP’s current model 
> without too much churn on the engine.

I think my fundamental question is: is it actually that useful? How 
often, in practice, do people want exact namespace matching, vs 
something more flexible?

-- 
Rowan Tommins
[IMSoP]