On 9 July 2024 04:24:59 BST, Mike Schinkel <m...@newclarity.net> wrote:
>I think maybe you are replying to an earlier iteration by Michael Morris and
>have not seen the more recent iteration?
I wrote the message a few days ago, but it didn't post; but the more recent
discussion still seems to be focussing on things that can be solved in
userland, rather than the fundamentally hard parts.
>There he explored adding an additional function to named `spl_autoload_map()`
>where the difference from `spl_autoload_register()` is that while the latter
>uses procedural code to determine what should be loaded the former would use a
>declarative map to determine what should be loaded. Then Composer and/or other
>tools could/would generate that map for PHP.
You can implement this in userland, right now. The point of calling procedural
code for the autoloader is that it can do anything it likes to define the
symbol - it can look it up in a table of directories, it can load some code
from a database and eval() it, whatever you need. In fact, Composer already
does implement such a file map, that's what its "optimize autoloader" option
creates.
What you can't easily do is run different code depending on where the symbol is
used - but since the autoloader is only called once per symbol, doing so
wouldn't make much sense.
>> My advice: start with the assumption that something has already installed
>> all the files you need into an arbitrary directory structure, and something
>> is going to generate a bunch of statements to load them.
>
[...]
>What works for user-managed apps is that each `add-on` (`plugin` in WordPress,
>`module` in Drupal) is stored in its own self-contained directory containing
>its own vendor code
Note that I said "arbitrary directory structure", not "PSR-4/Composer directory
structure"; the files are on disk somewhere. PHP didn't put them there, some
application did. The application knows where they are, and needs to tell PHP
somehow.
> — where some of the vendor code could easily be duplicated in another add-on
This is the hard part I was suggesting you focus on.
> and then the user-managed apps itself manages loading of all add-ons itself
> without a PSR-4 autoloader. As it exists, there are no standard for how
> add-on filenames and directory structures much be named nor how they are to
> load their dependencies so it is impossible for WordPress or Drupal to take
> on that role using PSR-4 for them.
WordPress doesn't need PHP Internals, or even PHP-FIG, to define how plugins
should be laid out on disk, and to write an autoloader for whatever they come
up with.
>Michael Morris' idea to add an `spl_autoload_map()` function would allow
>addressing the needs of user-managed apps that treat each add-on as a
>self-contained entity. But making the assumption that "something has already
>installed all the files you need into an arbitrary directory structure" is not
>sufficient for the problems Michael Morris and I have been trying to address.
It doesn't need to solve all the needs of the application, it needs to solve
the parts we don't already have. WordPress already knows how to download files
to disk; it could trivially design a system for plugin authors to lay out their
own classes in some agreed layout and write an autoloader using the
functionality that's been around since PHP 5.3.
The part it can't do is load two classes with the same fully-qualified name,
because the language has no base functionality to build that on. Designing
configuration files is a complete waste of time until you've designed that base
functionality: when you load two classes with the same fully-qualified name,
what exactly do you want the engine to do? What will need to change in the core
of the language to make that possible?
Regards,
Rowan Tommins
[IMSoP]
