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]
