Le 09/06/2026 à 02:37, Michael Morris a écrit :
On Mon, Jun 8, 2026 at 5:00 PM Rowan Tommins [IMSoP]
<[email protected]> wrote:
On 08/06/2026 16:36, Alex Rock wrote:
> Recently, we had proposals for "Friend classes" and "Pure PHP
files".
> These suggestions aren't new at all, but they demonstrate some
wish in
> the PHP ecosystem to make certain changes for PHP to be closer to
> other programming languages.
I don't think "being closer to other programming languages" is, or
should be, an aim of the project. Our aim should be to make PHP as
good
a language as it can be.
That includes borrowing ideas which have proved successful in other
languages, large and small, as well as avoiding pitfalls which
have been
revealed by those other languages. It also includes retaining PHP's
identity as a distinct language with its own history, user base, and
ecosystem.
As I've said in previous discussions, JavaScript's module system was
designed around a very specific set of facilities and constraints. It
has some similarity to Python, which uses some of the same concepts
(e.g. all definitions are essentially anonymous objects, named by
assigning to variables).
PHP has an entirely different set of facilities and constraints, much
more similar to Java and C# (e.g. all definitions have a globally
unique
name, namespace imports are primarily short-hand for those unique
names).
Your proposal looks very much like trying to wedge JavaScript's
solution
into PHP, rather than a realistic path forward for PHP's existing
ecosystem.
--
Rowan Tommins
[IMSoP]
I see the bear is out for it's yearly walk eh? At least I wasn't the
one who woke it this time.
Kidding aside.
Changing the language for change sake is a non-starter Alex. First,
what is the problem you want to solve?
The largest problem a module system could solve is resolving namespace
conflicts. If you delve into the discussion Rowain and I had on this
last year it goes into detail on this to some degree, but the real
world problem is this. Suppose I write AkiPublish, a plugin for
Wordpress which uses composer to resolve dependencies. Suppose
someone else out there writes BobMod, a plugin to help moderate. For
whatever reason the two plugins want to use different incompatible
versions of a library called LogIt.
The end user will have a crash if they ever install these plugins
together. And if they're like 90% of WordPress users they won't have a
clue why. PHP has no mechanism for code isolation - plugins,
extensions, modules or whatever the heck you call them, they all must
share a global state. Careful coding mitigates most of this problem
and it is the reason Laravel, Symfony, Drupal et al take the form they
do - avoiding establishing global variables at all cost and putting
this into classes. But that isn't the architecture of WordPress and
indeed most of PHP before 5.3.
And while many are dismissive of Wordpress, it does have one of the
largest, perhaps the largest, footprints in the PHP CMS space.
True code isolation would be useful to have, but it needs to take a
form that is minimally disruptive. Rowain and I had worked out some
concepts, but I dropped the ball on this and got distracted with other
projects. To be honest, these days I spend as little time working with
computer code outside of work as I can because it just doesn't
interest me anymore. I wrestle with Dorico and try to actually "compose".
That said, at this time completion of the PHP-ASYNC project might be
prerequisite to doing this. The reason is simple - the best way to
isolate code packages is to put them on different threads. The moment
that happens calls to functions living on those threads will have to
be handled asynchronously. That's one of the reasons I've remained
silent on this for much of the last year.
Thanks Michael and Rowan for your quick insights, especially since I
have read some of your past conversations about Modules :)
So, let me try to answer your questions.
> First, what is the problem you want to solve?
The main problems that PHP modules solve are the following:
- Libraries can finally isolate code completely, and not only in private
class methods, but they can isolate entire structures, and can even
isolate a sub-library
- Since all modules internally contain a hashed-prefix version of all
their definitions, two versions of the same library can coexist, since a
module hash is unique based on its file path and contents (I should have
made it explicit that the module prefix is hashed based on file contents
& path, to ensure uniqueness)
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.
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. It can already
be bundled like that, but it needs a few hacks, whereas modules make it
directly built-in. We could imagine the FrankenPHP worker mode have one
base memory impact based on the modules tree, and all the rest would be
I/O-related memory consumption.
Having everything made into modules also allows giving more power to the
compiler and engine in order to control stack/heap-related structures:
garbage collection points can be more deterministic, objects references
can be tracked a bit more easily, and so on.
> I don't think "being closer to other programming languages" is, or
should be, an aim of the project. Our aim should be to make PHP as
good a language as it can be.
You're right, and that's the reason why, since modules have been
requested for some time now, I think the best way to have this feature
is to ensure its integration smoothly in the compiler and engine.
> True code isolation would be useful to have, but it needs to take a
form that is minimally disruptive. Rowain and I had worked out some
concepts, but I dropped the ball on this and got distracted with other
projects. To be honest, these days I spend as little time working with
computer code outside of work as I can because it just doesn't interest
me anymore. I wrestle with Dorico and try to actually "compose".
That's why my thoughts are about doing it in two steps: first make sure
that a module is "harmless when loaded", ensuring proper impact-free
compilation and structure-definition, so that the compiler can guarantee
that such compiled file is "safe", or "pure" (in the means of "no impact
on external code", apart compiler-detectable issues, like existing
classes, constants, etc.), and that userland can still use this file
without BC breaks. And as said, this "simple feature" makes all existing
codebases still work the same.
As I already said: the main goal isn't to resemble JS or other
languages. It's to solve the aforementioned problems in a way that can
be both close to existing languages (for familiarity), and smooth on the
ecosystem (which the proposed two steps are for the ecosystem, but the
second step is heavy on the engine).
