On 09/06/2026 10:39, Alex Rock wrote:
Many existing libraries could migrate parts of their internal structures (the ones not supposed to be supported by their BC policy) to modules with no impact on userland code.
I think this is the crux for me, and why I reacted as I did to your initial e-mail. It doesn't look anything like how PHP libraries lay out their code today, so migrating to it would involve a complete change of coding style.
In JavaScript, it has always been common practice to ship libraries as a single file, so the user only needed to add a single <script> tag. Inside that file, a single function creates a private scope, and everything declared is hidden unless passed out in some way. The modern module format still basically works that way: "import" references a file, and "export" defines objects to pass back.
In PHP, we've always had include/require, and for the last 20+ years, we've had autoloading, so packages commonly have many small files. Libraries have always prefixed names to avoid colliding with other code, and namespaces made that easier. Loading a package usually means configuring an autoloader to look in directory X for namespace prefix Y, and reference the classes you need by name.
Changing every file in a library to use import and export statements would be a huge chore, and break all sorts of assumptions, for very little benefit. The natural boundary in PHP is not an included file, it's a registered namespace prefix.
And the future of this might help improving the ecosystem by providing a different way to package applications themselves: if the first loaded file is a module, and all files in the module tree are also modules and all "include/require" are done on compiler-resolvable paths, this means that an entire PHP app could be bundled as the opcodes.
OpCache already handles the difference between per-file compilation and "linking" between files; the reason not to ship opcodes is more about the stability of the OpCode format itself, which can change in even minor versions.
Module-level optimisation would potentially be a significant benefit, but again the key there is how to define a boundary around *multiple* files, to cache them as a single unit. If the cache key has to include *extra* granularity, for "file X imported from file Y" vs "file X imported from file Z", that just leads to more cache misses.
-- Rowan Tommins [IMSoP]
