Le 13/06/2026 à 19:14, Rowan Tommins [IMSoP] a écrit :
On 13 June 2026 16:32:08 BST, Michael Morris <[email protected]> wrote:
Namespaces in PHP are a bit of a hack - they prepend the stated namespace
to all labels declared in the file, and the use statement allows the fully
qualified name of a class, function or constant to be stated only once,
usually at the head of the file. It also allows aliasing, say if you have a
"Parser" class out of two different packages - you can alias them as
"FooParser" and "BarParser". It looks like Java or JavaScript importing,
but it isn't.
A small correction: this is exactly the same way that namespaces work in Java, with
exactly the same implication: the fully qualified class name has to be globally unique.
Java's solution to isolating an entire set of names is apparently to define an
"Isolated ClassLoader":
https://www.javathinking.com/blog/what-is-an-isolated-classloader-in-java/
C# also has this model of namespaces, but allows you to isolate a set of names from a particular
"assembly" using an "extern alias" statement:
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/extern-alias
I suspect both mechanisms rely on details of their respective runtimes that
wouldn't translate to PHP, but in principle what we're looking for is something
similar.
Rowan Tommins
[IMSoP]
Namespaces being just a globally accessible and define-able symbols
system is exactly why, so far, a PHP package cannot define "private
internal" code. The way the language works already allows
autoload-hijacking in order to override code from external libs, or even
hack the visibility (like removing "final" or "private" keywords before
autoloading the file...).
After 18 years of PHP coding, including 15 years as a professional, I've
seen a huge lot of legacy PHP projects that benefit the language's
flexibility. Sure thing many of businesses could succeed thanks to being
able to override almost everything (contrary to stricter languages), but
maintaining these codebases with up-to-date versions of PHP, or
3rd-party libs, is so much of a hassle that, at some point, lots of
maintainers are going more and more into adding new things into PHP that
enforce a bit more strictness, opt-in of course. Some other libs (I'm
thinking about EasyAdmin, in the Symfony ecosystem, for example) have
even made the choice to close pretty much everything and provide
"maintainable" public entrypoints, enforcing the Open/Close principle
with a strict approach (immutable final classes, stricter options and
arguments, etc.). It has its pros and cons, and can be frustrating for
some devs, but the main goal was to make maintenance a bit easier for
the core devs so that they are not forced to maintain BC on too many layers.
Introducing Modules, whether they are based on namespaces or not, would
help maintainers, I think, and could reinvent how we think of PHP
packages, while still keeping PHP what it has always been because it
would be opt-in for maintainers.
On my side, I don't care if modules are tightly coupled to namespaces or
not, and if more, that's even why my first idea was to bind a module to
a single-file at first, and making all modules imported from such file
being non-importable-again, thus creating a single module tree that can
be stored at compile-time, have no side-effect at load-time (which is a
big safeguard to avoid other issues), and allowing multiple modules of
seemingly same name to be loaded in the memory at the same time,
similarly to how Node.js allows having different versions of the same
packages to be installed, while also allowing to have one version used
by many modules too.
The only drawback of having modules like that would be that final
dependency trees in Composer would be non-flat, but again, I think this
non-flat system should be opt-in. Similarly to how flat systems are
opt-in in the Node.js ecosystem (and trust me, I've tried to enforce
"flat" dependencies resolutions in certain Node projects, and it's a
huge hassle). Luckily, the PHP ecosystem is quite fine so far, compared
to Node, and I would definitely keep the "flat" system in Composer for
as long as possible, and make non-flat resolutions only case-specific
(which is rare, and usually framework-dependent, like with Wordpress
plugins for instance).
I still hope we could have a grouped discussion on this.
Larry's Modules proposal (here:
https://github.com/Crell/php-rfcs/blob/master/modules/spec-brainstorm.md )
is IMO a very good starting point, and it only lacks the "multiple
modules with different versions". And module definition with an INI file
looks interesting.
Adding a "container" system when importing a module can maybe allow
this, I don't know...?
@Michael: do you think you could start a new thread for PHP containers?
Do you already have some research that you could bring for a pre-RFC
discussion?
