Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129157
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sat, 08 Nov 2025 22:56:07 +0100
To: internals@lists.php.net
Message-ID: <be5c97b7-430d-4d4e-b413-b331c85816e1@app.fastmail.com>
In-Reply-To: <72f90052-fa19-415c-9f5a-ae75275fd030@rwec.co.uk>
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>
Subject: Re: [PHP-DEV] RFC: Namespace-Scoped Visibility for Methods and Properties
Content-Type: multipart/alternative;
 boundary=82cf21be1589453bba216b0b3dfbdc3a
From: rob@bottled.codes ("Rob Landers")

--82cf21be1589453bba216b0b3dfbdc3a
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sat, Nov 8, 2025, at 22:20, Rowan Tommins [IMSoP] wrote:
> On 08/11/2025 20:08, Rob Landers wrote:
> > The moment we allow "namespace prefixes", we introduce questions tha=
t=20
> > need to be fleshed out separately and with care. Do we treat=20
> > "Acme\AuthLib\Session" and "Acme\AuthLib\Services" as related? Even =
if=20
> > they come from different vendors and are unrelated in any way? Are=20
> > namespaces hierarchical or just flat strings that happen to contain=20
> > separators?
>=20
>=20
> While I appreciate the desire to keep things simple, I don't think we=20
> can avoid asking those questions, we can only propose answers. In your=20
> current RFC, the answers are:
>=20
> - No two namespaces are related, even if their names imply a hierarchy.
> - Two "internal" classes in the same namespace can see each other even=20
> if they are written by different vendors.
>=20
>=20
> > Today namespaces are a name resolution mechanism, not a semantic=20
> > hierarchy. Matching by prefix would start treating them as a package=20
> > system, and I explicitly am trying to avoid that in this RFC.
>=20
> I don't think that's true. The language already recognises the namespa=
ce=20
> separator, and that if you are in namespace "Acme\AuthLib", an=20
> unqualified reference to "Services\SessionManager" refers=20
> to "Acme\AuthLib\Services\SessionManager". That doesn't require any=20
> concept of "package", but it is clearly based on the conception of=20
> namespaces as a hierarchy.
>=20
>=20
> > By restricting the rule to exact namespace equality, the feature is=20
> > straightforward to explain and to understand. It also prevents=20
> > "accidental" access because two unrelated namespaces happen to share=
 a=20
> > prefix.
>=20
> My concern is that by restricting it so much, we would prevent most of=20
> the real-world use cases for it, since the reality is that people use=20
> much more complex namespace hierarchies.
>=20
>=20
> > If you have a concrete, unambiguous rule for prefix-based access tha=
t=20
> > wouldn=E2=80=99t cause surprises or make assumptions about how peopl=
e organise=20
> > their codebases, I=E2=80=99d be happy to discuss it. Right now, ever=
y version=20
> > I=E2=80=99ve explored would reopen the "module"/"package" debate fro=
m this summer.
>=20
> I mentioned, briefly, two possibilities:
>=20
> > I think we need a keyword or attribute which takes as a parameter=20
> > either the namespace prefix, or the number of levels to match
>=20
> To spell those out, the prefix version could look like this:
>=20
> namespace Acme\AuthLib\Somewhere\Deep\In\Package;
> // ...
> #[NamespacePrivate('Acme\AuthLib', includeChildren: true)]
>=20
>=20
> A number of levels version could look like this:
>=20
> namespace Acme\AuthLib\Somewhere\Deep\In\Package;
> // ...
> #[NamespacePrivate(minLevels: 2, maxLevels: null)]
>=20
> There's all sorts of variations on how those arguments could be=20
> presented, keywords vs attributes, etc; but the key point is the=20
> language is not defining where the boundary is, it is requiring the us=
er=20
> to do so.
>=20
>=20
> The prefix-based approach could be expanded into an allow-list that=20
> didn't require any relationship to the current namespace at all:
>=20
>  namespace Acme\AuthLib\Somewhere\Deep\In\Package;
> // ...
> #[AllowNamespace('Acme\AuthLib\*')]
> #[AllowNamespace('Zeppo\FrameworkCore\*')]
>=20
> Or even an allow-deny rule system:
>=20
> #[AllowNamespace('Acme\AuthLib\*')]
> #[DenyNamespace('Acme\AuthLib\Plugins\*')]
>=20
> At that point, it's admittedly rather complex, but it makes *even fewe=
r*=20
> assumptions about what constitutes a "package".
>=20
>=20
> --=20
> Rowan Tommins
> [IMSoP]
>=20

Hi Rowan,

Thanks for expanding the examples.

Those approaches: prefix matching, wildcard matching, level-based matchi=
ng, or allow/deny lists are all significantly more expressive than what =
this RFC is aiming for. They move the discussion from "namespace -privat=
e visibility" into designing a generalised access-control system or a de=
-facto package model. That=E2=80=99s a much wider problem space, and wou=
ld need its own design work (and, likely, its own RFC).

The goal of this RFC is intentionally minimal: take the boundary that al=
ready exists in the language (the lexical namespace) and allow private v=
isibility to extend across it. Exact namespace equality keeps the rule u=
nambiguous, requires no new access-control model, and avoids assumptions=
 about how developers structure hierarchies.

I agree that broader forms of scoping could be useful, but they should b=
e in their own proposal. One advantage of keeping this RFC small is that=
 it can be expanded later without a BC break. For example, prefix matchi=
ng (maybe something like `private(namespace: Acme\AuthLib)`) or a protec=
ted-namespace variant could be layered on top if the community wants to =
go in that direction.

This RFC isn=E2=80=99t intended to solve the entire space; it=E2=80=99s =
the smallest useful step that seems to fairly cleanly fit into PHP=E2=80=
=99s current model without too much churn on the engine.

=E2=80=94 Rob
--82cf21be1589453bba216b0b3dfbdc3a
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Sat, Nov 8, 2025, at 22:20, Rowan Tommins [IMSoP] w=
rote:</div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On 08/11/=
2025 20:08, Rob Landers wrote:</div><div>&gt; The moment we allow "names=
pace prefixes", we introduce questions that&nbsp;</div><div>&gt; need to=
 be fleshed out separately and with care. Do we treat&nbsp;</div><div>&g=
t; "Acme\AuthLib\Session" and "Acme\AuthLib\Services" as related? Even i=
f&nbsp;</div><div>&gt; they come from different vendors and are unrelate=
d in any way? Are&nbsp;</div><div>&gt; namespaces hierarchical or just f=
lat strings that happen to contain&nbsp;</div><div>&gt; separators?</div=
><div><br></div><div><br></div><div>While I appreciate the desire to kee=
p things simple, I don't think we&nbsp;</div><div>can avoid asking those=
 questions, we can only propose answers. In your&nbsp;</div><div>current=
 RFC, the answers are:</div><div><br></div><div>- No two namespaces are =
related, even if their names imply a hierarchy.</div><div>- Two "interna=
l" classes in the same namespace can see each other even&nbsp;</div><div=
>if they are written by different vendors.</div><div><br></div><div><br>=
</div><div>&gt; Today namespaces are a name resolution mechanism, not a =
semantic&nbsp;</div><div>&gt; hierarchy. Matching by prefix would start =
treating them as a package&nbsp;</div><div>&gt; system, and I explicitly=
 am trying to avoid that in this RFC.</div><div><br></div><div>I don't t=
hink that's true. The language already recognises the namespace&nbsp;</d=
iv><div>separator, and that if you are in namespace "Acme\AuthLib", an&n=
bsp;</div><div>unqualified reference to "Services\SessionManager" refers=
&nbsp;</div><div>to&nbsp;"Acme\AuthLib\Services\SessionManager". That do=
esn't require any&nbsp;</div><div>concept of "package", but it is clearl=
y based on the conception of&nbsp;</div><div>namespaces as a hierarchy.<=
/div><div><br></div><div><br></div><div>&gt; By restricting the rule to =
exact namespace equality, the feature is&nbsp;</div><div>&gt; straightfo=
rward to explain and to understand. It also prevents&nbsp;</div><div>&gt=
; "accidental" access because two unrelated namespaces happen to share a=
&nbsp;</div><div>&gt; prefix.</div><div><br></div><div>My concern is tha=
t by restricting it so much, we would prevent most of&nbsp;</div><div>th=
e real-world use cases for it, since the reality is that people use&nbsp=
;</div><div>much more complex namespace hierarchies.</div><div><br></div=
><div><br></div><div>&gt; If you have a concrete, unambiguous rule for p=
refix-based access that&nbsp;</div><div>&gt; wouldn=E2=80=99t cause surp=
rises or make assumptions about how people organise&nbsp;</div><div>&gt;=
 their codebases, I=E2=80=99d be happy to discuss it. Right now, every v=
ersion&nbsp;</div><div>&gt; I=E2=80=99ve explored would reopen the "modu=
le"/"package" debate from this summer.</div><div><br></div><div>I mentio=
ned, briefly, two possibilities:</div><div><br></div><div>&gt; I think w=
e need a keyword or attribute which takes as a parameter&nbsp;</div><div=
>&gt; either the namespace prefix, or the number of levels to match</div=
><div><br></div><div>To spell those out, the prefix version could look l=
ike this:</div><div><br></div><div>namespace Acme\AuthLib\Somewhere\Deep=
\In\Package;</div><div>// ...</div><div>#[NamespacePrivate('Acme\AuthLib=
', includeChildren: true)]</div><div><br></div><div><br></div><div>A num=
ber of levels version could look like this:</div><div><br></div><div>nam=
espace Acme\AuthLib\Somewhere\Deep\In\Package;</div><div>// ...</div><di=
v>#[NamespacePrivate(minLevels: 2, maxLevels: null)]</div><div><br></div=
><div>There's all sorts of variations on how those arguments could be&nb=
sp;</div><div>presented, keywords vs attributes, etc; but the key point =
is the&nbsp;</div><div>language is not defining where the boundary is, i=
t is requiring the user&nbsp;</div><div>to do so.</div><div><br></div><d=
iv><br></div><div>The prefix-based approach could be expanded into an al=
low-list that&nbsp;</div><div>didn't require any relationship to the cur=
rent namespace at all:</div><div><br></div><div>&nbsp;namespace Acme\Aut=
hLib\Somewhere\Deep\In\Package;</div><div>// ...</div><div>#[AllowNamesp=
ace('Acme\AuthLib\*')]</div><div>#[AllowNamespace('Zeppo\FrameworkCore\*=
')]</div><div><br></div><div>Or even an allow-deny rule system:</div><di=
v><br></div><div>#[AllowNamespace('Acme\AuthLib\*')]</div><div>#[DenyNam=
espace('Acme\AuthLib\Plugins\*')]</div><div><br></div><div>At that point=
, it's admittedly rather complex, but it makes *even fewer*&nbsp;</div><=
div>assumptions about what constitutes a "package".</div><div><br></div>=
<div><br></div><div>--&nbsp;</div><div>Rowan Tommins</div><div>[IMSoP]</=
div><div><br></div></blockquote><div><br></div><div>Hi Rowan,</div><div>=
<br></div><div>Thanks for expanding the examples.</div><div><br></div><d=
iv>Those approaches: prefix matching, wildcard matching, level-based mat=
ching, or allow/deny lists are all significantly more expressive than wh=
at this RFC is aiming for. They move the discussion from "namespace -pri=
vate visibility" into designing a generalised access-control system or a=
 de-facto package model. That=E2=80=99s a much wider problem space, and =
would need its own design work (and, likely, its own RFC).</div><div><br=
></div><div>The goal of this RFC is intentionally minimal: take the boun=
dary that already exists in the language (the lexical namespace) and all=
ow private visibility to extend across it. Exact namespace equality keep=
s the rule unambiguous, requires no new access-control model, and avoids=
 assumptions about how developers structure hierarchies.</div><div><br><=
/div><div>I agree that broader forms of scoping could be useful, but the=
y should be in their own proposal. One advantage of keeping this RFC sma=
ll is that it can be expanded later without a BC break. For example, pre=
fix matching (maybe something like `private(namespace: Acme\AuthLib)`) o=
r a protected-namespace variant could be layered on top if the community=
 wants to go in that direction.</div><div><br></div><div>This RFC isn=E2=
=80=99t intended to solve the entire space; it=E2=80=99s the smallest us=
eful step that seems to fairly cleanly fit into PHP=E2=80=99s current mo=
del without too much churn on the engine.</div><div><br></div><div id=3D=
"sig121229152">=E2=80=94 Rob</div></body></html>
--82cf21be1589453bba216b0b3dfbdc3a--