Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124074
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of
 ES6 from JavaScript
In-Reply-To: <CA+p1FaZjxQtJZNSfUoU9q5DNNP+3URsmuRBc_xL988KOMZ31aQ@mail.gmail.com>
Date: Sun, 30 Jun 2024 02:45:15 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <FF092C59-E28F-4130-A446-CBBD0DA23114@newclarity.net>
References: <CAEUnE0fGZ3jFiBG=GyvnhBzH5a0iO4=n75PM=3+6zLAMrumEvA@mail.gmail.com>
 <CA+p1FaYYrQtV9vNmtNT+n6e_UospXH_czjN51UfAoQURwGoy7A@mail.gmail.com>
 <CAEUnE0ejmU7PuadTq5KMgW1fLz+EJNCVjhdKfXsc-sMzeiC+Nw@mail.gmail.com>
 <CAEUnE0cRc0F-UBtui-W-ovyxvwZhhV8YXADe_bDEyHWCxuFi4Q@mail.gmail.com>
 <CA+p1FaZjxQtJZNSfUoU9q5DNNP+3URsmuRBc_xL988KOMZ31aQ@mail.gmail.com>
To: David Gebler <davidgebler@gmail.com>
From: mike@newclarity.net (Mike Schinkel)

> On Jun 29, 2024, at 6:28 PM, David Gebler <davidgebler@gmail.com> =
wrote:
>=20
> On Sat, Jun 29, 2024 at 9:27=E2=80=AFPM Michael Morris =
<tendoaki@gmail.com> wrote:
>=20
> 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.
>=20
> 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.
>=20
> 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-yea=
rs/


>  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:=20

- Number of directory entries that popular projects end up managing.=20

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. =20
>=20
> 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.
>=20
> 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. =46rom the root of each repo:
>=20
> 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 =E2=80=94 and for those who use a debugger =E2=80=94=
 forces the developer to step into and then step out of the autoloader =
every time a new class or interface is loaded. =20

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 =E2=80=94 and this I 100% agree with you on, even if I =
lament it =E2=80=94 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=