Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124214 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id E1B2C1A009C for ; Thu, 4 Jul 2024 06:28:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1720074565; bh=zv4EwxAqhoY2DOzgmK1U+txX5tKvI0Sre2zHj3FiQaQ=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=PRM9QLMnE9sTcOI6BtUtpOPq6h02PLE5Np0dr3mMDVuxNnHL7Rfz5lCpxtqIDqR4h R0oG8qimc2YMfwiqoWF5dkveql4qwqFFwXkYH48j7DWSEim8ndQmb3IC1YSx7lcHSo y2hb8MPbJTFcydK3JDRxLpp1LC+Zkpnthb21yhvBtF41X6FdrhT5oRqWO04nnIvHSx 8SDs0tCn5r7rk/cQ6QlAV88EfkkcblSTTLGPet9xOoX6sing3r3XIytVHGieRrCDBW gVgwdptLuOMApytvlA3k7OLEwB0GRfdSLqQ0wAuFPbs4bbk7kQkCvUzI52LTgA3poy ftw5vyr85msWQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 36DD8180039 for ; Thu, 4 Jul 2024 06:29:24 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from fout2-smtp.messagingengine.com (fout2-smtp.messagingengine.com [103.168.172.145]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 4 Jul 2024 06:29:23 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfout.nyi.internal (Postfix) with ESMTP id 098E3138060B; Thu, 4 Jul 2024 02:28:01 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute1.internal (MEProxy); Thu, 04 Jul 2024 02:28:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm3; t=1720074481; x= 1720160881; bh=Tioj79UV0c7a+H1EM6jxt521pZ8lL++FLrjhyEXbA70=; b=o kNn4iIU088bAbzaaWInAkl2hUBJTuG2/ceH8bm6QWPs+wz3Jdq7PInggt0Etvijt 9gqeewPmHin0nHW2TU2KvNmA8+EPvObTa7qODKGAPTUGDfX6vi7h0eaYALyMyf3Z CyIHQh3yOAXR5OYGfx/XVeNKYc6gpBwAA45CZF1+nJk3yZbGpYqasUfJBu6ITron eW8dkgRH5Qjq0yO9yXZfqqGERlNhVcJPPGnbDrhMJN7iUVRqhHI8R/GuC1lwgpsb Nkm0Px/0idhOzms9jkIuVMCXWxeef+hk57eBBxL8xt6wlVkad1EnWKbdYHcs1Dm4 kfohCQuJH8jCgwovjKAgQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1720074481; x=1720160881; bh=Tioj79UV0c7a+H1EM6jxt521pZ8l L++FLrjhyEXbA70=; b=C5AJfkWsBLjTQH8D9W5DFZNCl/ExLEiHw2a2DnQog9lB /e5hHtaDKpBS5gj3BOW8LMXclerSHtEjZZZ3RwFemDIbveut/hB/2tEdN+cnFeZn S7/GfQugmlKtyJBX4hWiRzRP9Vx+M0x1JZRWeJr/Gvj5J1aQkzq5h5psklYgjNHL 1wJNhHG9WF+9+nO85f/n66ABhgffE0t4HiHlDazaSdot+Us9y64EKvKMOQAumpZr QfUvPTINKicOHO8XtIomzsB44ujkvsWJ3fn8rnJPL8kmCYfZGrAjfpinGQcFHI+1 MOzkPNmWiQsUoRcPCJ/k+qKV2M2Nl1T3SOvi4dMYkQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudekgddutdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerreejnecuhfhrohhmpedftfho sgcunfgrnhguvghrshdfuceorhhosgessghothhtlhgvugdrtghouggvsheqnecuggftrf grthhtvghrnhepgeegkeffgedvgeeitdduhffggefgleekgffgueduteetgeevueegteeu ieeuvdfhnecuffhomhgrihhnpehphhhprdhnvghtpdhmfihophdrnhgvthenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrohgssegsohhtthhl vggurdgtohguvghs X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 496FC15A0092; Thu, 4 Jul 2024 02:28:00 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-566-g3812ddbbc-fm-20240627.001-g3812ddbb Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 Message-ID: In-Reply-To: References: <09559430-4477-4516-8D78-6F4071E1AA6C@newclarity.net> <0182F3D6-F464-477F-9029-A2D0A8B50C71@koalephant.com> <1AFD7AAE-8BEA-460D-88A8-15BB3D30A775@koalephant.com> Date: Thu, 04 Jul 2024 08:26:32 +0200 To: "Matthew Weier O'Phinney" , "Stephen Reay" Cc: "Vincent de Lau" , "PHP internals" Subject: Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript) Content-Type: multipart/alternative; boundary=c9698a114fc84d7e9d56993d9954e93d From: rob@bottled.codes ("Rob Landers") --c9698a114fc84d7e9d56993d9954e93d Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 3, 2024, at 18:51, Matthew Weier O'Phinney wrote: >=20 >=20 > On Wed, Jul 3, 2024 at 9:50=E2=80=AFAM Stephen Reay wrote: >>=20 >>=20 >>> On 3 Jul 2024, at 21:07, Vincent de Lau wrote: >>>=20 >>> From: Stephen Reay =20 >>> Sent: Wednesday, July 3, 2024 1:17 PM >>>=20 >>>> On 1 Jul 2024, at 23:33, Mike Schinkel = wrote: >>>>> Autoloading runs userland code. This means it has the potential co= nflict between different packages with different autoloaders >>>=20 >>>> *Can* run userland code. It doesn't *have to*; FYI spl_autoload (h= ttps://www.php.net/manual/en/function.spl-autoload.php) has existed sinc= e php5.1 and works amazingly well.=20 >>>>=20 >>>> That "standards" like psr-whatever can't (read: choose not to) use = it says more about people and maintaining their little fiefdoms than any= thing else.=20 >>>=20 >>> As a PHP-FIG Core Committee member, I find this characterisation of = people involved in the FIG offensive. My contribution, however big or sm= all, is intended to help the PHP community at large. >>>=20 >>=20 >> If you choose to be offended by my opinion, I can't really help that.=20 >=20 > No, but you also don't need to air your personal grievances on the mai= ling list. If you don't like what FIG or any other entity in the PHP eco= system 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. >=20 > 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() alongsid= e the PSR recommendations or Composer; see more below. >>=20 >>> 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 nam= e it. If that is what projects wanted at the time, or even now, PSR-0 an= d the PHP-FIG would possibly not even exist. >>>=20 >>=20 >> It's less highly opinionated than either PSR, but that's my whole poi= nt: it's *someone else's opinion*, hence it's opposed by FIG. >=20 > That's a gross mischaracterization. >=20 > In point of fact, most frameworks that joined FIG in the beginning wer= e leveraging spl_autoload_register(), which provides a _stack_ of autolo= aders that each provide their own logic for how to map classes to where = on the filesystem they live. spl_autoload_register() came after spl_auto= load(), and was introduced *to add flexibility* to the language, as spl_= autoload is proscriptive and only allows a single approach to autoloadin= g, and it wasn't even one that was widely used at the time it was introd= uced. It's not about _opinions_, it's about recognizing that different a= pproaches might have merit. (Some might give better performance, some mi= ght allow pulling items out of a phar or tarball, etc.) >=20 > PSR-0 was created because a large number of projects were writing thei= r own autoloaders that were doing similar things, and most of them were = doing things _differently_ than spl_autoload() due to limitations of tha= t approach, and all were using spl_autoload_register(). Creating a stand= ard approach allowed users of these projects to use a single autoloader = to load code from each within their application, which helped improve pe= rformance and reduced autoloading conflicts. PSR-4 extended the concept,= while keeping some of the core ideas in place. And, again, YOU DO NOT N= EED TO FOLLOW either one. >=20 > Why? >=20 > 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 e= nsure it gets precedence. Composer's then becomes primarily a tool for l= oading the third-party code your application depends on. >>=20 >> Neither of which is the point I was making - someone claimed that aut= oloaders 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;= if 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* configura= ble 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 t= he class name. >>=20 >=20 > The configurable part for autoloading in the language is spl_autoload_= register(), full stop. And this _does_ require userland code. Yes, you c= an 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 sho= uldn't add any more to the engine; the stack approach of spl_autoload_re= gister() ensures we can reduce engine complexity and maintenance by offl= oading it to something that can evolve at a faster pace than the languag= e. >=20 > ----- >=20 > I'm following the packaging threads closely, and the one thing I've fa= iled 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 f= or marking things as package private (i.e., not part of the publicly con= sumable API), but that also feels like something we could address in oth= er ways. I know Larry has asked this same question before, and it's rea= lly what I want to see answered, because packages might be the solution,= but there may be other approaches we could take that also accomplish th= ose goals. >=20 > -- > Matthew Weier O'Phinney > mweierophinney@gmail.com > https://mwop.net/ > he/him Hi Mathew! My main feedback to PSR=E2=80=99s is that they are fundamentally broken = due to being outdated. The idea behind the standards is sound, but there= are only a few PSRs that are applicable to today=E2=80=99s PHP. When I = look at creating new libraries today, PSR=E2=80=99s are a good inspirati= on, but they probably shouldn=E2=80=99t be used in actual programs. Here= =E2=80=99s a short list of outdated standards I=E2=80=99ve collected ove= r the last couple of years: =E2=80=A2 7 =E2=80=A2 11 =E2=80=A2 15 =E2=80=A2 18 =E2=80=A2 20 Most of these breakdown if you start dealing with fibers, various new sc= opes introduced by runtimes, new http standards, etc.=20 Ergo, if you=E2=80=99ve run into these issues, you are likely inclined t= o stay as far away from PSR=E2=80=99s as reasonably possible and may hav= e a negative view of them. However, for enterprise applications, PSR=E2=80= =99s are a godsend. So they do have their uses, don=E2=80=99t get me wro= ng, but if you want to use technology newer than 2019-ish, you need to a= void them; and this is a large part of why I say PSR-XX isn=E2=80=99t a = valid argument on this list. All that being said, I=E2=80=99ve also looked into contributing over the= re, but my time is solidly booked up at the moment. Even on this list, I= mostly only participate on the train to/from work.=20 =E2=80=94 Rob --c9698a114fc84d7e9d56993d9954e93d Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jul 3, 2024, at 18:51, Matthew Weier O'Phinney wrote:
<= blockquote type=3D"cite" id=3D"qt" style=3D"">


On Wed, Jul 3, 2024 at 9:50=E2=80=AFAM Ste= phen Reay <php-lists@koal= ephant.com> wrote:


On 3 Jul 2024, at 21:07, Vincent de La= u <vincent@dela= u.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.&nbs= p;

That "standards" like psr-whatever can't= (read: choose not to) use it says more about people and maintaining the= ir little fiefdoms than anything else. 
=
As a PHP-FIG Core Committee member, I find this character= isation of people involved in the FIG offensive. My contribution, howeve= r big or small, is intended to help the PHP community at large.


If you choose to be offended by my opinion, I can't re= ally help that. 

No, but you also don't need to air your personal griev= ances on the mailing list. If you don't like what FIG or any other entit= y in the PHP ecosystem is doing, this is NOT the place to air that griev= ance. Internals is for discussing changes to the runtime. Calling out en= tities 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() alon= gside the PSR recommendations or Composer; see more below.

To come back to spl_autoload: That function pre-d= ates namespaces and is highly opinionated on how to organise code. All l= ower-case filenames, class per-file, files in include_path, full namespa= ce 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 op= posed 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 ea= ch provide their own logic for how to map classes to where on the filesy= stem they live. spl_autoload_register() came after spl_autoload(), and w= as introduced *to add flexibility* to the language, as spl_autoload is p= roscriptive and only allows a single approach to autoloading, and it was= n't even one that was widely used at the time it was introduced. It= 's not about _opinions_, it's about recognizing that different approache= s might have merit. (Some might give better performance, some might allo= w pulling items out of a phar or tarball, etc.)

<= /div>
PSR-0 was created because a large number of p= rojects were writing their own autoloaders that were doing similar thing= s, and most of them were doing things _differently_ than spl_autoload() = due to limitations of that approach, and all were using spl_autoload_reg= ister(). 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 conflict= s. PSR-4 extended the concept, while keeping some of the core ideas in p= lace. And, again, YOU DO NOT NEED TO FOLLOW either one.
=

Why?<= /span>

Because Composer uses spl_autoload_r= egister() 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 sta= ck using spl_autoload_register(). You can even add your own _before_ inv= oking the Composer autoloader to ensure it gets precedence. Composer's t= hen becomes primarily a tool for loading the third-party code your appli= cation depends on.

Neither of whic= h is the point I was making - someone claimed that autoloaders are impli= citly userland code. The point is they don't *have* to be, and there is = a perfectly useable one built in to the SPL extension; if it's "too opin= ionated" (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 addi= ng in more control shouldn't exactly require a rocket scientist to add, = for example, the ability to use the original case of the class name.
=


The co= nfigurable part for autoloading in the language is spl_autoload_register= (), full stop. And this _does_ require userland code. Yes, you can regis= ter spl_autoload() with it, and this is part of the engine, but that's t= he only language-level autoloader at this time. I'd argue we shouldn't a= dd any more to the engine; the stack approach of spl_autoload_register()= ensures we can reduce engine complexity and maintenance by offloading i= t to something that can evolve at a faster pace than the language.

-----

I'm fol= lowing the packaging threads closely, and the one thing I've failed to s= ee a solid argument for is _what problems_ the current approach of using= namespaced code doesn't address. I can definitely see a need for markin= g things as package private (i.e., not part of the publicly consumable A= PI), but that also feels like something we could address in other ways.&= nbsp; 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.

--
<= div dir=3D"ltr">
he/him

Hi Mathew!

<= div>My main feedback to PSR=E2=80=99s is that they are fundamentally bro= ken due to being outdated. The idea behind the standards is sound, but t= here are only a few PSRs that are applicable to today=E2=80=99s PHP. Whe= n I look at creating new libraries today, PSR=E2=80=99s are a good inspi= ration, but they probably shouldn=E2=80=99t be used in actual programs. = Here=E2=80=99s a short list of outdated standards I=E2=80=99ve collected= over the last couple of years:

  • 7
  • 11
  • 15
  • 18
  • 20
= Most of these breakdown if you start dealing with fibers, various new sc= opes introduced by runtimes, new http standards, etc. 

Ergo, if you=E2=80=99ve run into these issues, you are = likely inclined to stay as far away from PSR=E2=80=99s as reasonably pos= sible and may have a negative view of them. However, for enterprise appl= ications, PSR=E2=80=99s are a godsend. So they do have their uses, don=E2= =80=99t get me wrong, but if you want to use technology newer than 2019-= ish, you need to avoid them; and this is a large part of why I say PSR-X= X isn=E2=80=99t a valid argument on this list.

= All that being said, I=E2=80=99ve also looked into contributing over the= re, but my time is solidly booked up at the moment. Even on this list, I= mostly only participate on the train to/from work. 

=
=E2=80=94 Rob
--c9698a114fc84d7e9d56993d9954e93d--