On Sun, Jun 1, 2025, at 12:26 AM, Michael Morris wrote:
> $myModule = require_module('file/path');
>
> or perhaps
>
> const myModule = require_module('file/path');
>
> The module probably should return a static class or class instance, but
> it could return a closure. In JavaScript the dynamic import()
> statement returns a module object that is most similar to PHP's static
> classes, with each export being a member or method of the module object.
>
> Circling back to a question I know will be asked - what about
> autoloaders? To which I answer, what about them? If the module wants
> to use an autoloader it has to require one just as the initial php file
> that required it had to have done at some point. The container module
> is for all intents and purposes its own php process that returns some
> interface to allow it to talk to the process that spawned it.
>
> Will this work? I think yes. Will it be efficient? Hell no. Can it be
> optimized somehow? I don't know.
I think there's a key assumption here still that is at the root of much of the
disagreement in this thread.
Given that code from multiple files is clustered together into a "thing"
and Given we can use that "thing" to define a boundary for:
* name resolution (what Michael is after);
* visibility (what I am after);
* more efficient optimizations (what Arnaud showed is possible);
* various other things
Then the key question is: Who defines that boundary?
Is it the code *author* that defines that boundary? Or is it the code
*consumer*?
Similarly, is it the code author or consumer that has to Do Work(tm) in order
to leverage the desired capability? Or both?
This is an abstract question that I think needs to be resolved before we go any
further. There are certainly ways to do it with either party in control of the
boundary, but I suspect many of them will be mutually-exclusive, so deciding
which tradeoffs we want and what future features we're OK with blocking is
highly important.
My own take:
The boundary *must* be definable by the author. The author knows the code
better than the consumer. The odds of the author botching the boundary and
making subtle bugs is orders of magnitude less than the consumer of the code
botching the boundary. (Eg, if a class is declared module-private, but it's
the consumer that defines what module it is in, then access to that class is
completely out of the control of the author and it's really easy for some code
to break.) Potentially we could allow the consumer to decide how they want to
leverage that boundary (either by just using the code as is normally now, or
wrapping it into a name resolution container), but the boundary itself needs to
be author-defined, not consumer defined, or things will break.
I realize that makes it less useful for the goal of "support old and
unmaintained WordPress plugins that haven't been updated in 3 years" (as it
will be about 15 years before WP plugins that have bothered to make
modules/containers/boundaries get abandoned), but my priority is the
consistency and reliability of the language mroeso than supporting negligent
maintainers.
One possible idea: Starting from the proposal Arnaud and I made earlier (see
earlier posts), have a Module.php file rather than module.ini, which defines a
class that specifies the files to include/exclude etc. Then in addition to the
"just use as it is" usage pattern we described, the consumer could also run
something like:
$container = require_modules(['foo/Module.php', 'bar/Module.php'],
containerize: true);
Which would give back an object/class/thing through which all the code that was
just loaded is accessed, creating a separate loading space that is build along
the boundaries established by the module/package authors already. (Note: This
still relies on all of those packages being modularized by their authors, but
again, I think that is a requirement.)
--Larry Garfield
