Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124202
Precedence: bulk
MIME-Version: 1.0
References: <09559430-4477-4516-8D78-6F4071E1AA6C@newclarity.net>
 <0182F3D6-F464-477F-9029-A2D0A8B50C71@koalephant.com> <GV1PR01MB10526D0B220ED0AC9D1C17473C2DD2@GV1PR01MB10526.eurprd01.prod.exchangelabs.com>
 <1AFD7AAE-8BEA-460D-88A8-15BB3D30A775@koalephant.com>
In-Reply-To: <1AFD7AAE-8BEA-460D-88A8-15BB3D30A775@koalephant.com>
Date: Wed, 3 Jul 2024 11:51:39 -0500
Message-ID: <CAJp_myXHSHD6+76gyOs=d+cfVgwCmpuhKMtYcVBM6b-i3Bf0WQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial
 Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)
To: Stephen Reay <php-lists@koalephant.com>
Cc: Vincent de Lau <vincent@delau.nl>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000938de7061c5aa577"
From: mweierophinney@gmail.com ("Matthew Weier O'Phinney")

--000000000000938de7061c5aa577
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 3, 2024 at 9:50=E2=80=AFAM Stephen Reay <php-lists@koalephant.c=
om>
wrote:

>
>
> On 3 Jul 2024, at 21:07, Vincent de Lau <vincent@delau.nl> wrote:
>
> From: Stephen Reay <php-lists@koalephant.com>
> Sent: Wednesday, July 3, 2024 1:17 PM
>
> On 1 Jul 2024, at 23:33, Mike Schinkel <mailto:mike@newclarity.net> wrote=
:
>
> Autoloading runs userland code. This means it has the potential conflict
> between different packages with different autoloaders
>
>
> *Can* run userland code. It doesn't *have to*; FYI  spl_autoload (
> https://www.php.net/manual/en/function.spl-autoload.php) has existed
> since php5.1 and works amazingly well.
>
> That "standards" like psr-whatever can't (read: choose not to) use it say=
s
> more about people and maintaining their little fiefdoms than anything els=
e.
>
>
> As a PHP-FIG Core Committee member, I find this characterisation of peopl=
e
> involved in the FIG offensive. My contribution, however big or small, is
> intended to help the PHP community at large.
>
>
> If you choose to be offended by my opinion, I can't really help that.
>

No, but you also don't need to air your personal grievances on the mailing
list. If you don't like what FIG or any other entity in the PHP ecosystem
is doing, this is NOT the place to air that grievance. Internals is for
discussing changes to the runtime. Calling out entities like this here is
bound to alienate folks who want to work on the engine, and who are also
parts of those groups.

It also doesn't help your argument when you're stating things that are flat
out wrong as facts. You can absolutely use spl_autoload() alongside the PSR
recommendations or Composer; see more below.

>
> To come back to spl_autoload: That function pre-dates namespaces and is
> highly opinionated on how to organise code. All lower-case filenames, cla=
ss
> per-file, files in include_path, full namespace in path, you name it. If
> that is what projects wanted at the time, or even now, PSR-0 and the
> PHP-FIG would possibly not even exist.
>
>
>
> It's less highly opinionated than either PSR, but that's my whole point:
> it's *someone else's opinion*, hence it's opposed by FIG.
>

That's a gross mischaracterization.

In point of fact, most frameworks that joined FIG in the beginning were
leveraging spl_autoload_register(), which provides a _stack_ of autoloaders
that each provide their own logic for how to map classes to where on the
filesystem they live. spl_autoload_register() came after spl_autoload(),
and was introduced *to add flexibility* to the language, as spl_autoload is
proscriptive and only allows a single approach to autoloading, and it
wasn't even one that was widely used at the time it was introduced. It's
not about _opinions_, it's about recognizing that different approaches
might have merit. (Some might give better performance, some might allow
pulling items out of a phar or tarball, etc.)

PSR-0 was created because a large number of projects were writing their own
autoloaders that were doing similar things, and most of them were doing
things _differently_ than spl_autoload() due to limitations of that
approach, and all were using spl_autoload_register(). Creating a standard
approach allowed users of these projects to use a single autoloader to load
code from each within their application, which helped improve performance
and reduced autoloading conflicts. PSR-4 extended the concept, while
keeping some of the core ideas in place. And, again, YOU DO NOT NEED TO
FOLLOW either one.

Why?

Because Composer uses spl_autoload_register() internally, and enables
multiple autoloading approaches (PSR-0, PSR-4, classmap, file, etc.) out of
the box. And if you don't want to use those for your own code... you can
add another autoloader to the stack using spl_autoload_register(). You can
even add your own _before_ invoking the Composer autoloader to ensure it
gets precedence. Composer's then becomes primarily a tool for loading the
third-party code your application depends on.

>
> Neither of which is the point I was making - someone claimed that
> autoloaders are implicitly userland code. The point is they don't *have* =
to
> be, and there is a perfectly useable one built in to the SPL extension; i=
f
> it's "too opinionated" (or the opinions are ones you don't like), it's
> hardly the most in-depth of functions, and it already *has* configurable
> parts, so adding in more control shouldn't exactly require a rocket
> scientist to add, for example, the ability to use the original case of th=
e
> class name.
>
>
The configurable part for autoloading in the language is
spl_autoload_register(), full stop. And this _does_ require userland code.
Yes, you can register spl_autoload() with it, and this is part of the
engine, but that's the only language-level autoloader at this time. I'd
argue we shouldn't add any more to the engine; the stack approach of
spl_autoload_register() ensures we can reduce engine complexity and
maintenance by offloading it to something that can evolve at a faster pace
than the language.

-----

I'm following the packaging threads closely, and the one thing I've failed
to see a solid argument for is _what problems_ the current approach of
using namespaced code doesn't address. I can definitely see a need for
marking things as package private (i.e., not part of the publicly
consumable API), but that also feels like something we could address in
other ways.  I know Larry has asked this same question before, and it's
really what I want to see answered, because packages might be the solution,
but there may be other approaches we could take that also accomplish those
goals.

--=20
Matthew Weier O'Phinney
mweierophinney@gmail.com
https://mwop.net/
he/him

--000000000000938de7061c5aa577
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 3, 2024 at 9:50=E2=80=AFA=
M Stephen Reay &lt;<a href=3D"mailto:php-lists@koalephant.com">php-lists@ko=
alephant.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div><br id=3D"m_751423187916291872lineBreakAtBeginningOfMessag=
e"><div><br><blockquote type=3D"cite"><div>On 3 Jul 2024, at 21:07, Vincent=
 de Lau &lt;<a href=3D"mailto:vincent@delau.nl" target=3D"_blank">vincent@d=
elau.nl</a>&gt; wrote:</div><br><div><div>From: Stephen Reay &lt;<a href=3D=
"mailto:php-lists@koalephant.com" target=3D"_blank">php-lists@koalephant.co=
m</a>&gt; <br>Sent: Wednesday, July 3, 2024 1:17 PM<br><br><blockquote type=
=3D"cite">On 1 Jul 2024, at 23:33, Mike Schinkel &lt;mailto:<a href=3D"mail=
to:mike@newclarity.net" target=3D"_blank">mike@newclarity.net</a>&gt; wrote=
:<br><blockquote type=3D"cite">Autoloading runs userland code. This means i=
t has the potential conflict between different packages with different auto=
loaders<br></blockquote></blockquote><br><blockquote type=3D"cite">*Can* ru=
n userland code. It doesn&#39;t *have to*; FYI =C2=A0spl_autoload (<a href=
=3D"https://www.php.net/manual/en/function.spl-autoload.php" target=3D"_bla=
nk">https://www.php.net/manual/en/function.spl-autoload.php</a>) has existe=
d since php5.1 and works amazingly well.=C2=A0<br><br>That &quot;standards&=
quot; like psr-whatever can&#39;t (read: choose not to) use it says more ab=
out people and maintaining their little fiefdoms than anything else.=C2=A0<=
br></blockquote><br>As a PHP-FIG Core Committee member, I find this charact=
erisation of people involved in the FIG offensive. My contribution, however=
 big or small, is intended to help the PHP community at large.<br><br></div=
></div></blockquote><div><span style=3D"color:rgb(0,0,0)"><br></span></div>=
<div><font color=3D"#000000"><span>If you choose to be offended by my opini=
on, I can&#39;t really help that.=C2=A0</span></font></div></div></div></bl=
ockquote><div><br></div><div>No, but you also don&#39;t need to air your pe=
rsonal grievances on the mailing list. If you don&#39;t like what FIG or an=
y other entity in the PHP ecosystem is doing, this is NOT the place to air =
that grievance. Internals is for discussing changes to the runtime. Calling=
 out entities like this here is bound to alienate folks who want to work on=
 the engine, and who are also parts of those groups.</div><div><br></div><d=
iv>It also doesn&#39;t help your argument when you&#39;re stating things th=
at are flat out wrong as facts. You can absolutely use spl_autoload() along=
side the PSR recommendations or Composer; see more below.</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div><div><div><span style=3D"color:r=
gb(0,0,0)"><br></span></div><div><blockquote type=3D"cite">To come back to =
spl_autoload: That function pre-dates namespaces and is highly opinionated =
on how to organise code. All lower-case filenames, class per-file, files in=
 include_path, full namespace in path, you name it. If that is what project=
s wanted at the time, or even now, PSR-0 and the PHP-FIG would possibly not=
 even exist.</blockquote></div><blockquote type=3D"cite"><div><div><br></di=
v></div></blockquote><div><br></div><div>It&#39;s less highly opinionated t=
han either PSR, but that&#39;s my whole point: it&#39;s *someone else&#39;s=
 opinion*, hence it&#39;s opposed by FIG.</div></div></div></blockquote><di=
v><br></div><div>That&#39;s a gross mischaracterization.</div><div><br></di=
v><div>In point of fact, most frameworks that joined FIG in the beginning w=
ere leveraging spl_autoload_register(), which provides a _stack_ of autoloa=
ders that each provide their own logic for how to map classes to where on t=
he filesystem they live. spl_autoload_register() came after spl_autoload(),=
 and was introduced *to add flexibility* to the language, as spl_autoload i=
s proscriptive and only allows a single approach to autoloading, and it was=
n&#39;t even one that was widely=C2=A0used at the time it was introduced. I=
t&#39;s not about _opinions_, it&#39;s about recognizing that different app=
roaches might have merit. (Some might give better performance, some might a=
llow pulling items out of a phar or tarball, etc.)</div><div><br class=3D"g=
mail-Apple-interchange-newline"><span style=3D"">PSR-0 was created because =
a large number of projects were writing their own autoloaders that were doi=
ng similar things, and most of them were doing things _differently_ than sp=
l_autoload() due to limitations of that approach, and all were using spl_au=
toload_register(). Creating a standard approach allowed users of these proj=
ects to use a single autoloader to load code from each within their applica=
tion, which helped improve performance and reduced=C2=A0autoloading conflic=
ts. PSR-4 extended the concept, while keeping some of the core ideas in pla=
ce. And, again, YOU DO NOT NEED TO FOLLOW either one.</span><br></div><div>=
<span style=3D""><br></span></div><div><span style=3D"">Why?</span></div><d=
iv><br></div><div>Because Composer uses spl_autoload_register() internally,=
 and enables multiple autoloading approaches (PSR-0, PSR-4, classmap, file,=
 etc.) out of the box. And if you don&#39;t want to use those for your own =
code... you can add another autoloader to the stack using spl_autoload_regi=
ster(). You can even add your own _before_ invoking the Composer autoloader=
 to ensure it gets precedence. Composer&#39;s then becomes primarily a tool=
 for loading the third-party code your application depends on.</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div><div><div><br></div><div>Ne=
ither of which is the point I was making - someone claimed that autoloaders=
 are implicitly userland code. The point is they don&#39;t *have* to be, an=
d there is a perfectly useable one built in to the SPL extension; if it&#39=
;s &quot;too opinionated&quot; (or the opinions are ones you don&#39;t like=
), it&#39;s hardly the most in-depth of functions, and it already *has* con=
figurable parts, so adding in more control shouldn&#39;t exactly require a =
rocket scientist to add, for example, the ability to use the original case =
of the class name.</div><div><br></div></div></div></blockquote><div><br></=
div><div>The configurable part for autoloading in the language is spl_autol=
oad_register(), full stop. And this _does_ require userland code. Yes, you =
can register spl_autoload() with it, and this is part of the engine, but th=
at&#39;s the only language-level autoloader at this time. I&#39;d argue we =
shouldn&#39;t add any more to the engine; the stack approach of spl_autoloa=
d_register() ensures we can reduce engine complexity and maintenance by off=
loading it to something that can evolve at a faster pace than the language.=
</div></div><div><br></div><div>-----</div><div><br></div>I&#39;m following=
 the packaging threads closely, and the one thing I&#39;ve failed to see a =
solid argument for is _what problems_ the current approach of using namespa=
ced code doesn&#39;t address. I can definitely see a need for marking thing=
s as package private (i.e., not part of the publicly consumable API), but t=
hat also feels like something we could address in other ways.=C2=A0 I know =
Larry has asked this same question before, and it&#39;s really what I want =
to see answered, because packages might be the solution, but there may be o=
ther approaches we could take that also accomplish those goals.<br clear=3D=
"all"><div><br></div><span class=3D"gmail_signature_prefix">-- </span><br><=
div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><div>Matthew Wei=
er O&#39;Phinney<br><a href=3D"mailto:mweierophinney@gmail.com" target=3D"_=
blank">mweierophinney@gmail.com</a><br><a href=3D"https://mwop.net/" target=
=3D"_blank">https://mwop.net/</a></div><div>he/him<br></div></div></div></d=
iv>

--000000000000938de7061c5aa577--