> On Jun 29, 2024, at 6:28 PM, David Gebler <davidgeb...@gmail.com> wrote: > > On Sat, Jun 29, 2024 at 9:27 PM Michael Morris <tendo...@gmail.com> wrote: > > Near universal unity?? You're forgetting Wordpress, which has massive PHP > market share (more than 50% of PHP backed websites - well more than depending > on which survey you cite) and DOES NOT USE COMPOSER. And it DOES NOT USE > PSR-4 either. > > Composer is wonderful as a userland solution to a problem the Internals team > has failed to solve, but such a critical problem as package management being > mostly solved in userland using a configuration file (composer.json) written > in another programming language entirely is frankly an embarrassment in my > opinion. > > Given WP has yet to adopt Composer or PSR-4 standards, how likely do you > think it is that this particular project will be quicker to adopt any, say, > PHP 10 "user modules" feature along the lines of what you've proposed?
As someone who worked with WordPress as a plugin developer for about 10 years, I would say WordPress would be HIGHLY likely to adopt modules if modules could possibly integrate into WordPress without WordPress having to make the nature of wholesale changes that you are others are objecting to related to PHP. Note they have yet to adopt namespaces in any significant way (or at least if they did it has been very recent.) I was heavily involved in a trac discussion where people were proposing to use Composer for WordPress to manage plugins and their dependencies. I pointed out that Composer is a build-time solution for PHP where WordPress has no concept of build-time and that all configuration and 3rd party package "deployment" is done using a running WordPress install, and most often by end-users how have no clue how to resolve a conflict in dependencies (such as two plugins is same function name.) Consequently I argued that using Composer for WordPress as proposed was a non-starter. That trac ticket was opened eight years ago, and is still open with no action (because action without rewriting WordPress is impossible IMO.): https://core.trac.wordpress.org/ticket/36335 ALL THAT SAID, I do not see WordPress using modules as the new approach for plugins. Same problems would exist as for Composer unless PHP added "un_include" and "un_require" functionality. And even then I don't know if there would be enough of an impedance match to use modules for plugins. However, what I **do** see WordPress doing is adding new features using modules, and I **do** see plugin developers embracing modules (and especially if one module could be substituted for another module at runtime without worrying about symbol naming conflicts.) #fwiw > Mmm, been hearing that one for the last twenty years, yet here we are. And > the improvements to the language in that time have been innumerable Here is a recent article that I think is insightful to review: https://thenewstack.io/why-php-usage-has-declined-by-40-in-just-over-2-years/ > None of those languages have better inherent support for packages than PHP, > just different ways of doing it. "Better" is a subjective term. Let me give one objective criteria: - Number of directory entries that popular projects end up managing. I am sure each of us could (and should) come up with additional objective criteria for evaluating approaches to packages/modules (this is copied from an earlier email and I have quoted it so I can add a new paragraph after it): > And the PHP language encourages a large amount of file and directory bloat. > > One only need to compare the number of files in most PHP libraries to the > number of files in JS or Go package to see that the nature of a language > clearly does not influence. > > To bring stats vs. opinion I asked ChatGPT what the two equivalent packages > are to Symphony for JS and Go respectively and it suggested ExpressJS and > Gin. So I cloned them to see the number of files and directories each has. > From the root of each repo: > > Project Files Dirs > Symfony: 12,504 2,162 > ExpressJS: 259 87 > Gin(GoLang): 145 30 So, does "fewer files" make it "better?" That would be hard to prove or disprove, but it is a metric developers can consider when evaluating approaches to packages/modules. They can ask themselves if they really want to have to deal with so many files and folders when programming, or if they would prefer only working with an order of magnitude fewer files and folders. And only each individual developer can answer that question for themselves; they cannot answer that question for others. > PHP's way is namespaces and autoloading and while there's a good case that if > we were designing the language from scratch today, these might be a couple of > just many things all of us might want to do differently, ultimately all these > things are just variants of loading code symbols into scope. These languages > all have separate tools to manage third party dependency libraries (more than > one competing with each other, in some cases). Composer compares more to pip > or npm or maven, not Java packages or modules in Python, JS, etc. One of the downsides of how PHP loads code is that the loading code runs in slower userland code — and for those who use a debugger — forces the developer to step into and then step out of the autoloader every time a new class or interface is loaded. Is that bad? It is to me, but each developer must characterize those objective facts somewhere along the spectrum of good to bad for themselves. > For me, bottom line is I don't have any problem today managing or installing > versioned vendor code in my projects, I don't have a problem breaking my > project file structure down into clear modules and I don't have a problem > referencing those modules from other modules. "...that you are recognizing at the moment." (If you are being honest with your characterization.) Those problems exists, you have just acclimated to them and no longer notice them, or maybe you never did. > What I'm saying to you is that you need something much more comprehensive, > well thought out and well justified to be in a position to even have a > conceptual, ready-to-consider RFC. You don't need to have a working > implementation on day one but you need to be proposing something coherent and > with clear benefits, which I don't think this is today. Said another way — and this I 100% agree with you on, even if I lament it — the PHP internals mailing list is not the place to flesh out ideas and collaborate with others in the PHP community. That is unless you are already one of the primary contributors to PHP, and even then the primary contributors start out working on their ideas with others they know off-list. #it_is_what_it_is -Mike
