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]
