On Wed, Jul 10, 2024, at 1:38 AM, Mike Schinkel wrote:
>> In fact, if you use an optimized/dumped autoloader, then Composer simply builds an internal
>> giant lookup table of what class maps to what file. PSR-4 is then *completely irrelevant* at
>> runtime. It's already one giant O(1) lookup map. That can be done *today*. That *is* done
>> today.
>
> Yes, it can be done today. It *is* done today. By. Developer. Managed.. Apps.
> Already done. I explained how an spl_autoload_map() would do exactly
> that above.
>
>> When you have a proven that it's even possible to have multiple local symbol tables,
>> we can talk. Until then, please spare us.
>
> My one useful takeaway from your email — except that I already knew
> that — was the need to figure out how PHP can handle multiple symbol
> tables. Beyond that, your take your own advice and spare us (me) from
> your contempt and condescension as they are not good looks on anyone.
I find it amusing that several of your responses to me saying "you could do this stupid thing
but no one does that" is "WordPress does that thing." I make no comment other than
to observe it.
But let me understand: In a thread started by Michael Morris where he explicitly said the most
important thing for him is multi-version loading, you're going to insist you're talking
only about moving Composer's classmap logic into core, and nothing about multi-version loading.
If that's the case, then please be polite to Michael Morris and get out of his thread.
Also, be aware that classmap-in-core was already discussed 3 years ago and went nowhere.
https://wiki.php.net/rfc/autoload_classmap
https://externals.io/message/113545
Largely because, as Sara said then, and Rowan just said on this thread, it can be done better in
user-space and is already done better in user-space... by Composer.
https://externals.io/message/113569
You even commented in that thread:
https://externals.io/message/113554
So it's not a new idea, it's an idea that's already been greeted with a general
"meh".
Yes, most "developer managed apps" use Composer today to side-step the "bajillion
autoloaders" problem. It's a solved problem.
Nothing precludes Wordpress from doing the same. I admittedly have not looked at WP's core in
a very long time, but I would be absolutely shocked if it wasn't pretty straightforward to
build code into WP core that looks at the source directories of all plugins, finds the classes
there, and builds a big index (stored in a cache directory or the database) that it can use in one
single autoloader registered by WP itself. I know that can be done, because that's exactly how
Drupal 7's autoloader worked.. I know, because I wrote it. In 2008. (It was later modified
by others, but the initial version was mine.)
That would work even with WP's "download code and drop it on disk" model.. That has
been possible since PHP 5.2 at least, when I wrote exactly that for Drupal. It wasn't even
that hard. Literally any "user managed app" could do the same.
Why hasn't WP core done that in order to make life easier for plugin developers and avoid
registering 50 separate autoloaders? I dunno, you should ask Matt Mullenweg. We have nothing to do
with it.
--Larry Garfield