> On Jul 11, 2024, at 10:32 AM, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> > wrote: > > On Thu, 11 Jul 2024, at 12:26, Mike Schinkel wrote: >> 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. > > This is a terrible analogy, IMHO. Here's a more pertinent one:
Sure, we can go back and forth and discredit each others analogies, but that's not going to change your mind nor likely mine. The crux of our disagreement is I see value on infrastructure services and you evidently do not. > If you want to solve autoloading in WordPress, this is the wrong forum. > > Firstly, anything you do in core will not be adopted by WordPress, because it > will be 5+ years before their minimum PHP version is high enough to use it. > You're going to have to write a userland polyfill anyway. That is what you are missing on this point. If PHP supported a cascading class map autoloader then a developer could build their sites and their plugins for that version of PHP without having to depend on WordPress changing to support it. And if they are distributing plugins they could build fallback mechanisms for earlier versions of PHP plus also recommend to their users that they upgrade to the newer versions of PHP. It is about empowering individuals developers, not about empowering WordPress. But, like I said, since anyone could no it, evidently no one will. > Secondly, mapping namespaces to directories isn't the hard part for > WordPress. The hard part is integrating into their existing plugin installer > system - which already has a system for metadata, it doesn't need a new > config file - and persuading plugin authors to actually use it. No, integrating into the plugin system would actually be quite easy per the class map design we've been discussing. I know the internals of that system well, I've probably debugged through it literally hundreds of times. And sorry, the existing metadata system in WordPress has no information about plugin dependencies and is inadequate for that purpose. It only has an ini-like plugin header with basic information and is not suitable for dependencies. Also, "persuading plugin authors to actually use it" won't change a thing because they are already using it effectively, generally speaking. > Maybe you also need Composer to make some changes to control it without the > CLI, so plugins can list their requirements and have them installed centrally. That well could be. > That's also not a subject for this list. And we disagree, yet again. Anyway, I am trying to avoid this thread so I can instead invest time in research and proof-of-concept work. Please don't pull me back in. -Mike
