Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124064
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <CAEUnE0cRc0F-UBtui-W-ovyxvwZhhV8YXADe_bDEyHWCxuFi4Q@mail.gmail.com>
Date: Sat, 29 Jun 2024 23:28:34 +0100
Message-ID: <CA+p1FaZjxQtJZNSfUoU9q5DNNP+3URsmuRBc_xL988KOMZ31aQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of
 ES6 from JavaScript
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002c48a0061c0ee3c9"
From: davidgebler@gmail.com (David Gebler)

--0000000000002c48a0061c0ee3c9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 29, 2024 at 9:27=E2=80=AFPM Michael Morris <tendoaki@gmail.com>=
 wrote:

>
> Near universal unity??  You're forgetting Wordpress, which has massive PH=
P
> 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 DOE=
S
> 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 frank=
ly
> 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?


> What is asking for more trouble is to stagnate, sit-on-hands, and twenty
> years from now PHP will be where COBOL is today - a niche programming
> language that was once widely used, but reviled, hated, and the current
> generation of programmers working feverishly to remove it entirely. Not t=
o
> mention the butt of an awful lot of jokes.
>

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, but
each one has served as a solution to a clear problem statement.


> No one is going to post to this list with a perfect plan to solve package
> management in CORE.   Not in userland - we've got that - in CORE.  That i=
s
> a feature PHP lacks that is present in Java, NodeJS (not clientside JS, a
> distinction needs to be made), C#, Python and Go (likely others, but thos=
e
> are the ones I've used and whose implementations I am familiar with on at
> least a cursory level.)
>

None of those languages have better inherent support for packages than PHP,
just different ways of doing it. 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.

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. Nor is the way I do
those things different to how any other PHP project does those things (be
that via Composer, another custom autoloading function, a series of require
statements, or whatever).


> And I also don't appreciate the notion that any solution proposed here
> should be 100% perfect and ready for implementation day one.  That's neve=
r
> going to happen.  But I'm not willing to join several talented programmer=
s
> that have spent a month to a year getting a working implementation into
> place before submitting an RFC only to have it shot down after work has
> been done.  Cause frankly, I think some of y'all are only here to shoot
> ideas down and never come up with new ones.
>

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.

--0000000000002c48a0061c0ee3c9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sat, Jun 29, 2024 at 9:27=E2=80=AFPM M=
ichael Morris &lt;<a href=3D"mailto:tendoaki@gmail.com">tendoaki@gmail.com<=
/a>&gt; wrote:</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=
=3D"ltr"><div dir=3D"ltr"></div><div dir=3D"ltr" class=3D"gmail_attr"><br><=
/div><div>Near universal unity??=C2=A0 You&#39;re forgetting Wordpress, whi=
ch has massive PHP market share (more than 50% of PHP backed websites - wel=
l more than depending on which survey you cite) and DOES NOT USE COMPOSER. =
And it DOES NOT USE PSR-4 either.</div><div><br></div><div>Composer is wond=
erful as a userland solution to a problem the Internals team has failed to =
solve, but such a critical problem as package management=C2=A0being mostly =
solved in userland using a configuration file (composer.json) written in an=
other programming language entirely is frankly an embarrassment in my=C2=A0=
opinion.</div></div></div></div></blockquote><div><br></div><div>Given WP h=
as 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 &quo=
t;user modules&quot; feature along the lines of what you&#39;ve proposed?</=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
 dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr"><div>What is askin=
g for more trouble is to stagnate, sit-on-hands, and twenty years from now =
PHP will be where COBOL is today - a niche programming language that was on=
ce widely used, but reviled, hated, and the current generation of programme=
rs working feverishly to remove it entirely. Not to mention the butt of an =
awful lot of jokes.</div></div></div></div></blockquote><div><br></div><div=
>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, but e=
ach one has served as a solution to a clear problem statement.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><div dir=3D"ltr"><div>No one is going to pos=
t to this list with a perfect plan to solve package management in=C2=A0CORE=
.=C2=A0 =C2=A0Not in userland - we&#39;ve got that - in CORE.=C2=A0 That is=
 a feature PHP lacks that is present in Java, NodeJS (not clientside=C2=A0J=
S, a distinction needs to be made), C#, Python and Go (likely others, but t=
hose are the ones I&#39;ve used and whose implementations=C2=A0I am familia=
r with on at least a cursory level.)</div></div></div></div></blockquote><d=
iv><br></div><div>None of those languages have better inherent support for =
packages than PHP, just different ways of doing it. PHP&#39;s way is namesp=
aces and autoloading and while there&#39;s a good case that if we were desi=
gning 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 o=
ne 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.</div><di=
v><br></div><div>For me, bottom line is I don&#39;t have any problem today =
managing or installing versioned vendor code in my projects, I don&#39;t ha=
ve a problem breaking my project file structure down into clear modules and=
 I don&#39;t have a problem referencing those modules from other modules. N=
or is the way I do those things different to how any other PHP project does=
 those things (be that via Composer, another custom autoloading function, a=
 series of require statements, or whatever).</div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gm=
ail_quote"><div dir=3D"ltr"><div>And I also don&#39;t appreciate the notion=
 that any solution proposed here should be 100% perfect and ready for imple=
mentation day one.=C2=A0 That&#39;s never going to happen.=C2=A0 But I&#39;=
m not willing to join several talented programmers that have spent a month =
to a year getting a working implementation into place before submitting an =
RFC only to have it shot down after work has been done.=C2=A0 Cause frankly=
, I think some of y&#39;all are only here to shoot ideas down and never com=
e up with new ones.<br></div></div></div></div></blockquote><div><br></div>=
<div>What I&#39;m saying to you is that you need something much more compre=
hensive, well thought out and well justified to be in a position to even ha=
ve a conceptual, ready-to-consider RFC. You don&#39;t need to have a workin=
g implementation on day one but you need to be proposing something coherent=
 and with clear=C2=A0benefits, which I don&#39;t think this is today.</div>=
</div></div>

--0000000000002c48a0061c0ee3c9--