Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129153
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sat, 08 Nov 2025 21:08:34 +0100
To: internals@lists.php.net
Message-ID: <c0bfa15e-1df2-4d87-8092-2531b2bafcb3@app.fastmail.com>
In-Reply-To: <f1f694d7-d494-45c5-a4e4-fb39809d3b67@rwec.co.uk>
References: <e21b1992-d426-46cd-b86a-6d6a5844c934@app.fastmail.com>
 <f1f694d7-d494-45c5-a4e4-fb39809d3b67@rwec.co.uk>
Subject: Re: [PHP-DEV] RFC: Namespace-Scoped Visibility for Methods and Properties
Content-Type: multipart/alternative;
 boundary=d59da614b3b04e50bb9184b0bfbc054a
From: rob@bottled.codes ("Rob Landers")

--d59da614b3b04e50bb9184b0bfbc054a
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sat, Nov 8, 2025, at 17:50, Rowan Tommins [IMSoP] wrote:
> On 08/11/2025 12:43, Rob Landers wrote:
> > I=E2=80=99d like to introduce an RFC for discussion:=20
> > https://wiki.php.net/rfc/namespace_visibility which proposes a new=20
> > visibility modifier: private(namespace).
>=20
>=20
> Hi Rob,
>=20
> Thanks for putting together the RFC.
>=20
> My main concern with this and similar single-keyword proposals is that=20
> its only useful if people lay out their code in a particular way, rath=
er=20
> than fitting with the variety of namespace hierarchies seen in the wil=
d.
>=20
> For instance, in your example, you have two classes:
>=20
> - App\Auth\SessionManager
> - App\Auth\SessionStore
>=20
> But if this was library with a set of interchangeable session stores, =
it=20
> might well lay them out like this:
>=20
> - Acme\AuthLib\Session\Manager
> - Acme\AuthLib\Session\Store\SessionStoreInterface
> - Acme\AuthLib\Session\Store\DatabaseSessionStore
> - Acme\AuthLib\Session\Store\FileSystemSessionStore
> - etc
>=20
> In that case, "current namespace plus children" would work, and I'd be=20
> interested in your reasoning for requiring an exact match instead.
>=20
>=20
> But even that might not be enough, if for some reason it looked like t=
his:
>=20
> - Acme\AuthLib\Services\SessionManager
> - Acme\AuthLib\Implementations\SessionStore\SessionStoreInterface
> - Acme\AuthLib\Implementations\SessionStore\DatabaseSessionStore
> - Acme\AuthLib\Implementations\SessionStore\FileSystemSessionStore
> - etc
>=20
> Here, what we want is visibilty for everything inside "Acme\AuthLib",=20
> not only in "Acme\AuthLib\Services".
>=20
> Since, as you say in another reply, we don't have a standard definitio=
n=20
> of "module", "package", or "assembly", I think we need a keyword or=20
> attribute which takes as a parameter either the namespace prefix, or t=
he=20
> number of levels to match.
>=20
>=20
> --=20
> Rowan Tommins
> [IMSoP]
>=20

Hi Rowan,

Thanks for the detailed feedback. The exact-match requirement is intenti=
onal rather than incidental. In my nested classes RFC, I assumed namespa=
ces behaved hierarchically, and it was pointed out that isn=E2=80=99t al=
ways guaranteed. So, one of the main design goals with this RFC was to m=
ake a boundary that was crisp and unsurprising: if two pieces of code ha=
ve the same lexical namespace, access is allowed; if not, it isn=E2=80=99=
t. There's no need to consider namespace depth, prefixes, or directory l=
ayout.

The moment we allow "namespace prefixes", we introduce questions that ne=
ed 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 hierarch=
ical or just flat strings that happen to contain separators?

Today namespaces are a name resolution mechanism, not a semantic hierarc=
hy. Matching by prefix would start treating them as a package system, an=
d I explicitly am trying to avoid that in this RFC.

By restricting the rule to exact namespace equality, the feature is stra=
ightforward 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 prefi=
x-based visibility could be layered on top. For this RFC, I=E2=80=99m ai=
ming for a feature that provides enforceable encapsulation using the bou=
ndaries PHP already defines, albeit, loosely through name resolution.

If you have a concrete, unambiguous rule for prefix-based access that wo=
uldn=E2=80=99t cause surprises or make assumptions about how people orga=
nise their codebases, I=E2=80=99d be happy to discuss it. Right now, eve=
ry version I=E2=80=99ve explored would reopen the "module"/"package" deb=
ate from this summer.

=E2=80=94 Rob
--d59da614b3b04e50bb9184b0bfbc054a
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 17:50, Rowan Tommins [IMSoP] w=
rote:</div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On 08/11/=
2025 12:43, Rob Landers wrote:</div><div>&gt; I=E2=80=99d like to introd=
uce an RFC for discussion:&nbsp;</div><div>&gt;&nbsp;<a href=3D"https://=
wiki.php.net/rfc/namespace_visibility">https://wiki.php.net/rfc/namespac=
e_visibility</a>&nbsp;which proposes a new&nbsp;</div><div>&gt; visibili=
ty modifier: private(namespace).</div><div><br></div><div><br></div><div=
>Hi Rob,</div><div><br></div><div>Thanks for putting together the RFC.</=
div><div><br></div><div>My main concern with this and similar single-key=
word proposals is that&nbsp;</div><div>its only useful if people lay out=
 their code in a particular way,&nbsp;rather&nbsp;</div><div>than fittin=
g with the variety of namespace hierarchies seen in the wild.</div><div>=
<br></div><div>For instance, in your example, you have two classes:</div=
><div><br></div><div>- App\Auth\SessionManager</div><div>- App\Auth\Sess=
ionStore</div><div><br></div><div>But if this was library with a set of =
interchangeable session stores, it&nbsp;</div><div>might well lay them o=
ut like this:</div><div><br></div><div>- Acme\AuthLib\Session\Manager</d=
iv><div>- Acme\AuthLib\Session\Store\SessionStoreInterface</div><div>- A=
cme\AuthLib\Session\Store\DatabaseSessionStore</div><div>- Acme\AuthLib\=
Session\Store\FileSystemSessionStore</div><div>- etc</div><div><br></div=
><div>In that case, "current namespace plus children" would work, and I'=
d be&nbsp;</div><div>interested in your reasoning for requiring an exact=
 match instead.</div><div><br></div><div><br></div><div>But even that mi=
ght not be enough, if for some reason it looked like this:</div><div><br=
></div><div>- Acme\AuthLib\Services\SessionManager</div><div>- Acme\Auth=
Lib\Implementations\SessionStore\SessionStoreInterface</div><div>- Acme\=
AuthLib\Implementations\SessionStore\DatabaseSessionStore</div><div>- Ac=
me\AuthLib\Implementations\SessionStore\FileSystemSessionStore</div><div=
>- etc</div><div><br></div><div>Here, what we want is visibilty for ever=
ything inside "Acme\AuthLib",&nbsp;</div><div>not only in "Acme\AuthLib\=
Services".</div><div><br></div><div>Since, as you say in another reply, =
we don't have a standard definition&nbsp;</div><div>of "module", "packag=
e", or "assembly", I think we need a keyword or&nbsp;</div><div>attribut=
e which takes as a parameter either the namespace prefix, or the&nbsp;</=
div><div>number of levels to match.</div><div><br></div><div><br></div><=
div>--&nbsp;</div><div>Rowan Tommins</div><div>[IMSoP]</div><div><br></d=
iv></blockquote><div><br></div><div>Hi Rowan,</div><div><br></div><div>T=
hanks for the detailed feedback. The exact-match requirement is intentio=
nal rather than incidental. In my nested classes RFC, I assumed namespac=
es behaved hierarchically, and it was pointed out that isn=E2=80=99t alw=
ays guaranteed. So, one of the main design goals with this RFC was to ma=
ke a boundary that was crisp and unsurprising: if two pieces of code hav=
e the same lexical namespace, access is allowed; if not, it isn=E2=80=99=
t. There's no need to consider namespace depth, prefixes, or directory l=
ayout.</div><div><br></div><div>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?</div><div><br></div><div>Today namespaces are a nam=
e resolution mechanism, not a semantic hierarchy. Matching by prefix wou=
ld start treating them as a package system, and I explicitly am trying t=
o avoid that in this RFC.</div><div><br></div><div>By restricting the ru=
le to exact namespace equality, the feature is straightforward to explai=
n and to understand. It also prevents "accidental" access because two un=
related namespaces happen to share a prefix.</div><div><br></div><div>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=E2=80=99m aimi=
ng for a feature that provides enforceable encapsulation using the bound=
aries PHP already defines, albeit, loosely through name resolution.</div=
><div><br></div><div>If you have a concrete, unambiguous rule for prefix=
-based access that wouldn=E2=80=99t cause surprises or make assumptions =
about how people organise their codebases, I=E2=80=99d be happy to discu=
ss it. Right now, every version I=E2=80=99ve explored would reopen the "=
module"/"package" debate from this summer.</div><div><br></div><div id=3D=
"sig121229152">=E2=80=94 Rob</div></body></html>
--d59da614b3b04e50bb9184b0bfbc054a--