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
