Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124213 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 9AA381A009C for ; Thu, 4 Jul 2024 04:32:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1720067604; bh=g5dZHY8k4GBC+a0TGkL+fOSDKiTT2SSzcamRMF9Z/lA=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=BG/JaiG/jOmlBI93C3UBkf324kAOKS9lF2zC1FXqSVli70CdfkC8+DooO37FcCPXr vk0bVhRDAquJ7WhldLVNUcwJm6hvp9jPo7SuCyyyBZoatFJWAvvwag9QrBP57vSnw6 qDPDBBIqD//D06u2izksNdsGSzERR383vdepiGOpCrjxieF+fdoC4xBuGylckCpcEn Auhp388c0YUQifbWEiMmcA/1FadGpdtpjtr61KfeMgCMaqZmLuVRd6lZfiwdg2OeA3 FpvBD9cv4KF7v0k9FiILL1Rm4edm2neXA3jGMVYJirRrHkAdOXGia/w6LlGLnnfCq+ hz4YTUSkPYPkA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 4A32B1807ED for ; Thu, 4 Jul 2024 04:33:23 +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.8 required=5.0 tests=BAYES_50,DMARC_MISSING, HTML_MESSAGE,SPF_HELO_NONE,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 mail1.25mail.st (mail1.25mail.st [206.123.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 4 Jul 2024 04:33:22 +0000 (UTC) Received: from smtpclient.apple (unknown [49.48.221.3]) by mail1.25mail.st (Postfix) with ESMTPSA id 758D060342; Thu, 4 Jul 2024 04:31:51 +0000 (UTC) Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_13D4B09E-9B63-4F95-8F54-9BEA2011A08C" Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript) Date: Thu, 4 Jul 2024 11:31:38 +0700 In-Reply-To: Cc: Vincent de Lau , PHP internals To: Matthew Weier O'Phinney References: <09559430-4477-4516-8D78-6F4071E1AA6C@newclarity.net> <0182F3D6-F464-477F-9029-A2D0A8B50C71@koalephant.com> <1AFD7AAE-8BEA-460D-88A8-15BB3D30A775@koalephant.com> X-Mailer: Apple Mail (2.3774.600.62) From: php-lists@koalephant.com (Stephen Reay) --Apple-Mail=_13D4B09E-9B63-4F95-8F54-9BEA2011A08C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 3 Jul 2024, at 23:51, Matthew Weier O'Phinney = wrote: >=20 >=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 = conflict between different packages with different autoloaders >>>=20 >>>> *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.=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 = anything 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 = small, 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 = 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. >=20 I'm glad we're in agreement that this list is about the runtime and not = about composer or FIG. I look forward to seeing a response from you as = vivid as this one, the next time someone responds to a discussion about = something like function autoloading with "X isn't really a problem = because composer".=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() alongside = the PSR recommendations or Composer; see more below Please re-read what I wrote, before making ironic statements about = 'facts'. I never said you can't use them "along side" each other. I said = that the PSR's are incapable of using the built-in functionality = provided by spl_autoload. That is: you can't adhere to either PSR using = the builtin autoloader alone. That you can use them along-side each = other is *unrelated* to `spl_autoload`, it's a function of the stack = created by `spl_autoload_register`. > . >>=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 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. >>>=20 >>=20 >> 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. >=20 > That's a gross mischaracterization. >=20 > 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.) >=20 spl_autoload, spl_autoload_register, and spl_autoload_extensions were = all added in php5.1 (compare https://3v4l.org/H60EG#v5.0.5 vs = https://3v4l.org/H60EG#v5.1.0). Maybe you're thinking of __autoload, = which had no default implementation before `spl_autoload` was added.=20 > The configurable part for autoloading in the language is = spl_autoload_register(), full stop.=20 spl_autoload is (and has been since inception) configurable via = spl_autoload_extensions, and via the standard include path. --Apple-Mail=_13D4B09E-9B63-4F95-8F54-9BEA2011A08C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 3 Jul 2024, at 23:51, Matthew Weier O'Phinney = <mweierophinney@gmail.com> wrote:



On Wed, = Jul 3, 2024 at 9:50=E2=80=AFAM Stephen Reay <php-lists@koalephant.com> = 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<= /a>) has existed since php5.1 and works amazingly = well. 

That "standards" like psr-whatever can't (read: = choose not to) use it says more about people and maintaining their = little fiefdoms than anything else. 

As a = PHP-FIG Core Committee member, I find this characterisation of people = involved in the FIG offensive. My contribution, however big or small, is = intended to help the PHP community at = large.



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

Please re-read = what I wrote, before making ironic statements about 'facts'. I never = said you can't use them "along side" each other. I said that the PSR's = are incapable of using the built-in functionality provided by = spl_autoload. That is: you can't adhere to either PSR using the builtin = autoloader alone. That you can use them along-side each other is = *unrelated* to `spl_autoload`, it's a function of the stack created by = `spl_autoload_register`.

.

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 projects wanted at the time, or even now, PSR-0 and the = PHP-FIG would possibly not even exist.


I= t'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.)

<= div>

spl_autoload, spl_autoload_register, = and spl_autoload_extensions were all added in php5.1 (compare https://3v4l.org/H60EG#v5.0.5&n= bsp;vs https://3v4l.org/H60EG#v5.1.0).=  Maybe you're thinking of __autoload, which had no default = implementation before `spl_autoload` was = added. 


The configurable part for autoloading in the language is = spl_autoload_register(), full = stop. 

spl_autoload is (and has been since inception) configurable = via spl_autoload_extensions, and via the standard include = path.



= --Apple-Mail=_13D4B09E-9B63-4F95-8F54-9BEA2011A08C--