Preface: I am going to bow out of this conversation now (unless pulled back in) and come back after 8.4 settles.
In the mean time I'll be working on two proof-of-concepts. One is a totally userland PoC for packages being able to load same-named symbols, and the other will be working out how to use multiple symbol tables in PHP core. And as I have never modified php-src before, that is going to take some learning. However, below are responses to Rowan and Larry. > On Jul 10, 2024, at 8:33 AM, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> > wrote: > > On Wed, 10 Jul 2024, at 07:38, Mike Schinkel wrote: >> The request is to add class maps with a PHP-standardized format into >> PHP core so that when a library of code needs to register classes to be >> autoloaded they can contribute to a cascading of class maps where ONE >> internal function checks the single union of all class maps for a >> mapped symbol before turning over control if no such symbol is found in >> the map to the procedural autoloaders that are currently available. >> That way *any* PHP code could register its own class map without having >> to get the core app to rearchitect itself to allow that to happen. > > Everything you've just described is possible, today, with no changes to PHP > core. I described a **standardized format** that would be processed by PHP, How exactly can any one individual implement a standardized format on their own, today? One that anyone can depend on to be recognized and processed by any version of PHP after the one that first implemented it? Rhetorical question. Of course. > So let's step back a second, and look at the pros and cons of implementing it > in core: > > Pros: > - Possibly a bit faster if the C code can be optimised > - "Blessed" by the PHP project, which makes it a standard of sorts Or — without the blessing of a standard — as we sometimes say in the USA: "Besides that Mrs Lincoln, how was the play?" Let me use an analogy. Envision two people on a city council of a small town. One proposes the city should implement a water, power and sewer grid so anyone who wants to build a new home or business in the city would be able to do so easily. The other argues that anyone wanting to build can set up their own generator, dig their own well, and dig their own septic tank so why should the city provide such a grid? After all, anyone who is motivated enough can build "today," right? Clearly that latter argument ignores the value of a central authority providing infrastructure others can just depend on existing, minimizing their cost, effort and risk. It also ignores that without that infrastructure most simply won't build there. In PHP some bits like nice-to-have functions are easy enough to relegate to userland — although str_starts_with() and str_ends_with() sure are nice to just have like a community center in that city which all residents can use. OTOH, for infrastructure services, PHP benefits itself and others by providing them even if someone could build the functionality themselves. To be clear, the fact something is an infrastructure service itself is not sufficient to argue it *must* be included in PHP core — the need for service itself should stand on its own. However, it is enough (IMO) to show "you can do it yourself today" is not a valid argument against an infrastructure service. So can we please instead focus on the pros and cons of having such an infrastructure service instead of using the canard "you can build it yourself" as an argument against roads, power, and sewers? If yes, we should discuss your list of pros and cons. HOWEVER, I think it is probably best to postpone any additional discussion until after 8.4 is released and any initial bugs are worked out so anyone interested could focus on the reasoning. > On Jul 10, 2024, at 10:07 AM, Larry Garfield <la...@garfieldtech.com> wrote: > > 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. And I observe you are imprecise when making your observation. WordPress as an entity does not do that thing. Plugin developers do. Independently. Because they have not been given any other viable option. > 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. Where did you get that from what I wrote? I acknowledged that a next step is doing a proof-of-concept exploration of multi-symbol tables in PHP core, *not* that needing to be able to load same-named symbols was something new to me. And Michael Morris proposed spl_autoload_map(). I was just advocating for it. > If that's the case, then please be polite to Michael Morris and get out of > his thread. Once again, you make incorrect assumptions. > 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. See the explanation to Rowan above about why doing it in user-space is not a valid argument against everything that can be done in user-space. > https://externals.io/message/113569 > > You even commented in that thread: > > https://externals.io/message/113554 Yeah, but unlike now I was super busy and could not contribute much to that debate. > So it's not a new idea, it's an idea that's already been greeted with a > general "meh". Property Hooks were once a general "meh." too. ¯\_(ツ)_/¯ > Yes, most "developer managed apps" use Composer today to side-step the > "bajillion autoloaders" problem. It's a solved problem. Or said another way with, in a nod to history "Let them eat cake." > 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. You make a fair point there. However, as it is a case "anyone could address," no one will. BTW, there is a benefit **beyond** just WordPress developers to having a core autoload map format in PHP that can just be expected to work. With that I could publish a library to be used by ANY PHP app, regardless of what autoloader it needs. Wikipedia even has a few relevant entries: https://en.wikipedia.org/wiki/Interoperability <https://en.wikipedia.org/wiki/Interoperability> https://en.wikipedia.org/wiki/Network_effect <https://en.wikipedia.org/wiki/Network_effect> That said, as I said above, I am going to go away for now and come back after 8.4 settles. -Mike
