> On Jun 29, 2024, at 6:28 PM, David Gebler <[email protected]> wrote:
>
> On Sat, Jun 29, 2024 at 9:27 PM Michael Morris <[email protected]> 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