Le 16/06/2026 à 06:45, Michael Morris a écrit :
On Mon, Jun 15, 2026 at 5:45 AM Alex Rock <pierstoval@gmail.com> wrote:
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...).
PHP has never kept people from shooting themselves in the foot. And in the past it's came with some big guns too (Register Globals in PHP 3 anyone?). Enforcing namespace visibility will come at a cost in performance, and it won't be enough to stop people from shooting themselves because PHP code is quite mutable. I don't see much of a point in trying to guide people's coding, especially in a language that doesn't have a set paradigm. That is, in Java, you're using classes. In PHP you can approach things that way, but you write purely procedurally. You can use the language as it was originally conceived - a templating language.
I think it's morally good to bring new features to the core that disallow someone from shooting themselves in the foot. Readonly classes, property hooks, etc., are methods for maintainers to be able to stricten their code so that end users don't shoot themselves in the foot. Yet we have the Reflection API that permits a huge lot of things, and combining with autoload hacking or bounded closures, it means that all these requirements, strictening tools, etc., are *contracts* we sign with maintainers. If someone uses any hacky tool built in PHP to override its native behavior, it's at their own risk. But the language allows it.
With my suggestion for modules, having all structures being declared globally but with a prefix still allows someone to hack into it. It just lowers the pressure on how it's developed in the core, in order for it to be both simple to use, but also simpler to implement. Doesn't prevent feet shots, but has a big warning sign nonetheless.
When you say modules, what are talking about, because multiple languages implement "modules" in different ways. JavaScript is the most well known, but Go also has modules and they are quite different and support versioning out of the box. In each of these examples there is a requirement that the programmer write code to import the modules at some place either in the project (Go) or in every bloody file in the project (JavaScript). PHP doesn't require this, instead autoloading symbol definitions as they are encountered.
There are different terms available for the things we talk about, so as a reminder to the two/three people reading this message:
* Module = file, similar to JS. This implies that everything defined
in the file is private, unless "publicly exposed", either via a
"public" keyword (as Larry suggests in his modules-brainstorming
document), or an "export" statement (similar to JS/TS).
* Module = package, in that case, this means that a module is composed
of several files, but a module/package needs an entrypoint to define
its components. Larry's aforementioned idea is about using an INI
file as entrypoint that prevents double-loading of a list of files,
but this could be implemented with other methods: my proposal for
"module = file" could add a "package" system without a need for an
INI file, and based purely on the list of publicly available
structures from the main imported file, but implies a bidirectional
relationship between the "main package file" (aka "entrypoint") and
the "package-included-only file". It's just a different approach.
None of these approaches removes namespaces, and considering my first idea and re-thinking it after all the comments in here, I think focusing on "using namespaces for that" is definitely the best approach. My proposal still stands, it just needs an update to better use namespaces for that need.
NPM (not Node, node is the engine not the package/dependency manager) does this using aliases. PHP doesn't have a way to alias symbols at compile time. It would be nice if it did - I've suggested it as a parameter to include not knowing at the time of the suggestion that include isn't a function, it's a statement, so `include "file.php"` is the same as `include("file.php")`. Setting that aside, PHP projects rarely execute the include themselves - they let an autoloader handle it, so the autoloader must know which version to load. This isn't something that even NPM does - it just aliases and makes both libraries available. The caller still must specify which library is being pulled in.
Node modules have a single point of entry, defined in the package.json file but usually index.js. In most Node packages this index.js imports all the public parts of the package and immediately exports them. Further, an import in node is an object (as is everything in JavaScript) that corresponds to that file. Hence
import { foo, bar } from 'MyPackage';
This is using JavaScripts dereference mechanic to pluck members of an object into the current symbol table. I could go on, but I think it's more on topic to just say that Node's import/export mechanic, elegant as it looks, is highly bound to JavaScript's scope rules and how its symbol table works. These aren't compatible with PHP.
I'm a bit familiar with Node.js's import model. PHP could be partly compatible with this in the future, but complete scoped encapsulation of a single PHP file is too much of a paradigm change for PHP itself. My proposal is making this "private" by prepending a null character and hash to all "included modules" whatever their kind, so that it /feels/ private, but still behaves similarly to how PHP currently works.
Less maintenance for the core team, zero BC break (purely additive and opt-in), can be transparent for the end-user (and *is* transparent for transient dependencies), still overridable and hackable by developers. Some of the reasons why PHP became famous in the first place.
For one, PHP has two symbol tables - one for variables (which is why all variables start with $ ) and one for everything else. Variables are affected by function scope, nothing else is. For example, if you define a function within a function in JavaScript that function will be private to the function it is defined in - it can't be seen in other scopes. In PHP the function will be visible on the symbol table.
For another, Node gives each file its own module scope. To move a symbol from one file to another you should use export and import. This creates a clear chain of custody for objects and symbols, but by God it also creates a LOT of boilerplate that the PHP community has no interest in replicating.
Without the chain of custody you rapidly run into trouble. It doesn't matter if you try to allow the user to put a prefix on the namespace as I once suggested, or have PHP's engine prefix it automagically somehow - you still need to correctly disambiguate every blasted reference to that namespace. This is no easy task - take a look at the code of Strauss - GitHub - BrianHenryIE/strauss: Prefix PHP namespaces and classnames to allow multiple versions of libraries to exist without conflict. · GitHub That project allows you to rewrite a package with a new namespace, in effect doing it in userland. But as a precaution it prefixes every single package imported and severs the tie back to the original packagist. Strauss is used by several WordPress plugins to make composer library use possible while still remaining portable between WordPress sites.
Interesting, and auto-prefixing namespaces for module=packages systems is IMO the easiest way to implement this without breaking the compiler nor the engine. It keeps everything as-is, and visually provides all that's needed for a "modules/packages" system to work: encapsulated private structures, an explicit public API, and the ability to load the same structures in the same namespaces because they are internally hidden with a hash, similarly to anonymous classes.
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 don't think it's a reasonable ask of Composer or any other dependency manager to try to resolve this without having a clear binding map like the one JavaScript forces you to create by how its module system works.
Composer doesn't have to change, because modules might be autoloadable. Whatever the solution found: if it's a bidirectional relationship (meaning any included file contains information on the "package" it's in, guiding to the entrypoint) or with a config file (like with an INI file), it can be built-in, and Composer would be compatible as long as loaded structures are public and not internal to the module.
This is the Container thread - I changed the subject line on my previous reply although I did include (was: ) so that people could track I was forking.
I don't have much to add beyond my previous post. I haven't heard from anyone with engine experience about the feasibility or difficulty of what I propose. To review (for anyone just joining but missing the previous message)
1. The user signals to the engine they want to include a php file AND process it independent of the current execution environment. No shared user defined symbols or variables.
2. That file returns an interface so that the calling thread can talk to the child.
3. As the processes reside on different threads these calls will need to be asynchronous to be optimal, otherwise the caller will be in a blocked state while the child executes the called method. It can work without the PHP Async / Await RFC's conclusion, but it won't be in ideal form without it.
Containers provide process isolation. Say I have a WordPress plugin that I want to use composer libraries with. Say, Guzzle. I can write my own container interface without touching Guzzle's code exposing the parts of Guzzle I need for my plugin. Since WordPress has no current core composer support I would need to carry a loader in my distro to be ran on the install hook of the plugin, bringing in composer and letting it in turn pull the libraries that I need to use. If someone later writes a plugin that uses an incompatible version of Guzzle that doesn't matter - even if they lazily load it into the main symbol table by not using a container. My plugin is isolated.
That isolation comes at a price. Each plugin has an independent vendor directory with no way to resolve complete redundancy. At least not in WordPress, which has no current composer implementation in core (I'm on the wp trac in a thread discussing it though).
There are open questions though that must be answered before this container idea is seriously explored. Most critical, can PHP be made to handle an object passing from one thread to another? That is, continuing from the example above, can a client instance from one GuzzleContainer coexist on the main thread with a client instance from a different container and referencing different code? Or will methods be unable to cross the barrier? What are the implications for the Reflection API and using it to examine an object that originated from another process thread referencing symbols that don't exist on the current thread?
The idea of containers is simple to state - but the implications are profound and might be unworkable. I simply don't know enough about the PHP engine to know.
This seems completely out of a "modules" scope to me: threading comes with a huge cost (like state interoperability, thread healthchecks, memory usage, and many other things), and this brings a lot of complexity that is not needed yet IMO. If someone wants to "sandbox" PHP somehow, it's already possible to execute another PHP script from inside a PHP script via CLI, and passing arguments to it, but there's no back-and-forth communication, only a "request-response-like" system.