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]