Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127351
Feedback-ID: id5114917:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 14 May 2025 09:08:13 +0100
To: internals@lists.php.net
Message-ID: <3ae9a6ea-f135-472b-b2bf-e6cd6ebad299@app.fastmail.com>
In-Reply-To: 
 <CADK1yXKg1xpneLs3vJ=nUAAGaVuBhqkEMgbBVaYfcBfQL2vkDg@mail.gmail.com>
References: 
 <CADK1yXKg1xpneLs3vJ=nUAAGaVuBhqkEMgbBVaYfcBfQL2vkDg@mail.gmail.com>
Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2
Content-Type: multipart/alternative;
 boundary=8feffb89df464153a8e1f947846e9207
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

--8feffb89df464153a8e1f947846e9207
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Tue, 13 May 2025, at 16:30, Deleu wrote:
> If we consider how GitHub, Composer and Docker Hub works, we can pin a very important aspect of "namespaces": {entity}/{project}. Entity may either be an individual or an organization, but the concept is mostly the same. Although it can be argued that PHP has nothing to do with that, I think that could be a "good-enough" foundation considering the complexity of the subject.

While a two-level namespace root for a project is common, it's far from universal. Picking two examples from the first page of "popular packages" on packagist.org, Guzzle's root namespace is one level ("GuzzleHttp\") and the Symfony Console component's root namespace is three levels ("Symfony\Component\Console\").

So I think any module or visibility tied to namespaces would need a way to declare that prefix explicitly, not have the language assume it's a particular length.

If we just want namespace visibility, we could use Scala's approach, where the private modifier itself can be qualified:

private[\Symfony\Component\Console] class Foo { ... }
private[\Symfony] class Bar { ... }

If we want modules to have more existence - module-wide declares, optimisation, etc - then we need some way of declaring "this namespace prefix is a module" - a "module" keyword, or "declare_module" function, or something. Those are the lines that Larry and Arnaud were exploring along a while ago - see https://github.com/Crell/php-rfcs/blob/master/modules/spec-brainstorm.md and https://github.com/arnaud-lb/php-src/pull/10

What Michael Morris is talking about is really a completely different concept - it's more like "containers", in the sense of Docker, Kubernetes, etc, where different sections of code can be isolated, and declare classes with conflicting fully-qualified names. I don't think it's what most applications and libraries would want "modules" to be; it's probably best thought of as a completely separate feature.

-- 
Rowan Tommins
[IMSoP]
--8feffb89df464153a8e1f947846e9207
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Tue, 13 M=
ay 2025, at 16:30, Deleu wrote:</div><blockquote type=3D"cite" id=3D"qt"=
 style=3D""><div dir=3D"ltr"><div>If we consider how GitHub, Composer an=
d Docker Hub works, we can pin a very important aspect of "namespaces": =
{entity}/{project}. Entity may either be an individual or an organizatio=
n, but the concept is mostly the same. Although it can be argued that PH=
P has nothing to do with that, I think that could be a "good-enough" fou=
ndation considering the complexity of the subject.<br></div></div></bloc=
kquote><div><br></div><div>While a two-level namespace root for a projec=
t is common, it's far from universal. Picking two examples from the firs=
t page of "popular packages" on packagist.org, Guzzle's root namespace i=
s one level ("GuzzleHttp\") and the Symfony Console component's root nam=
espace is three levels ("Symfony\Component\Console\").</div><div><br></d=
iv><div>So I think any module or visibility tied to namespaces would nee=
d a way to declare that prefix explicitly, not have the language assume =
it's a particular length.</div><div><br></div><div>If we just want names=
pace visibility, we could use Scala's approach, where the private modifi=
er itself can be qualified:</div><div><br></div><div>private[\Symfony\Co=
mponent\Console] class Foo { ... }</div><div>private[\Symfony] class Bar=
 { ... }</div><div><br></div><div>If we want modules to have more existe=
nce - module-wide declares, optimisation, etc - then we need some way of=
 declaring "this namespace prefix is a module" - a "module" keyword, or =
"declare_module" function, or something. Those are the lines that Larry =
and Arnaud were exploring along a while ago - see <a href=3D"https://git=
hub.com/Crell/php-rfcs/blob/master/modules/spec-brainstorm.md">https://g=
ithub.com/Crell/php-rfcs/blob/master/modules/spec-brainstorm.md</a> and&=
nbsp;<a href=3D"https://github.com/arnaud-lb/php-src/pull/10">https://gi=
thub.com/arnaud-lb/php-src/pull/10</a></div><div><br></div><div>What Mic=
hael Morris is talking about is really a completely different concept -&=
nbsp;it's more like "containers", in the sense of Docker, Kubernetes, et=
c, where different sections of code can be isolated, and declare classes=
 with conflicting fully-qualified names. I don't think it's what most ap=
plications and libraries would want "modules" to be; it's probably best =
thought of as a completely separate feature.</div><div><br></div><div>--=
 </div><div>Rowan Tommins</div><div>[IMSoP]</div></body></html>
--8feffb89df464153a8e1f947846e9207--