Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125490 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 044E91A00BD for ; Tue, 10 Sep 2024 17:59:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1725991296; bh=RfRg9aknfYYdRy1V8u63Sgb03JBMRg0yLk+0DlG0xi4=; h=Date:From:Cc:In-Reply-To:References:Subject:From; b=Rk8OcXq81Zy17vDwvRd93wlKDBkdLJpJ8Xubqpz9GqRm8quI7AwIzmWtGySSEQtT/ n3KkIzVNGmioh5SjrCN9wHCHnT3Q4+R8qsWfukFY0QBdMWaEvAcPyC6g70AamacvLn M/DRaxjLiazFPWNzHu39ytOQFSD9wzaUIfhvAqtXGV6HXIXaDr6JVsILUJ0LrGISKh z8txi9p282pvFHVVEwd2wYDx7LjZyQP5FdtD0nfwzLWZ/KeGLgea9xsaHLi4lGRCzq LC6l2/9MMQkQgXGT6WdYaaGYygMx8/3QKcrgEWeqkEqsUMHiRUdOCNh2Yt1OUnMaoI C/RSgRj8eXcgQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A2B5318005B for ; Tue, 10 Sep 2024 18:01:34 +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.9 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, MISSING_HEADERS,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from fout1-smtp.messagingengine.com (fout1-smtp.messagingengine.com [103.168.172.144]) (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 ; Tue, 10 Sep 2024 18:01:33 +0000 (UTC) Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfout.phl.internal (Postfix) with ESMTP id 1038C1380223 for ; Tue, 10 Sep 2024 13:59:32 -0400 (EDT) Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-01.internal (MEProxy); Tue, 10 Sep 2024 13:59:32 -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; s=fm2; t=1725991172; x=1726077572; bh=Wn/2JXO4D2kHlzubMn0NAK3e8x5ZGFGqJAbKX5iB2+w=; b=v08S+L1Kfjcf e2TZoRogej1+GlRN6d0vgH10hF9j8vw1cu75IlXueSCG+DQDAIqVWxwVwY/z2TuY P6XM6UJ9Dk3ZDV2FtWxzVclfcUgOACWWgKt3CC/eNa67SzgX+vXkvPjWudqzH1hR Jg1tUsm9/Ycb3a87ljP9gR2BL5bd42PodouHjlLvGoTuYYbgs5GLDB6NEee2Osw5 3QCD18pKIH7DenGWMB8c9NQ7u4Pzv2XdGTB6KV4a5WsKHIcgrDeUu2aArtRJbxyR 8bGx9DLjWWbYjTWSq4+UJfXn7qZpnwmxR0eYQSi50eS3Wse0vww8S0/gAs1fiQqy fxG3M1KrDw== 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 :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1725991172; x=1726077572; bh=Wn/2JXO4D2kHlzubMn0NAK3e8x5Z GFGqJAbKX5iB2+w=; b=LkhplKT/Bx8zadvFq9jdRcMAYlhXiJPoXY2Wu8f8Naaw rZjd+5qdgo8iYStAXIpJyAEPM7V6GGB3dkbg6N7NIoJVgyQ3RDnPngiEpVt625Ro d0TUFdOUM4Pt2m3LofrHQqZ214MqjV9zdRQ8xNBvSktpL1efqQdTXdhMieCUKuq6 bgH8GNouGjbWq4zs+PwsU+czlnU+D4rOwhZcPvs53Cd5fAgpuAxB+J9oQvJRcxaz x1cZt3HjjxloNPzlRQIwZcYcG89V6vACqRZrkAW9W6agKfb8mGeRR/57l4lBjlbX CaY7Nmsb1bNkjB5UDukhALVe5mYHALuKg6U1e2quJQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudeiledgudduudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecumhhishhsihhnghcuvf fquchfihgvlhguucdlfedtmdenucfjughrpefoggffhfevkfgjfhfutgesrgdtreerredt jeenucfhrhhomhepfdftohgsucfnrghnuggvrhhsfdcuoehrohgssegsohhtthhlvggurd gtohguvghsqeenucggtffrrghtthgvrhhnpefgffeuueeujedvgeeigefhtdeitddufeeu hfettdevheejieefjeegkedtgfevgfenucffohhmrghinhepphhhphdrnhgvthenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrohgssegsohht thhlvggurdgtohguvghspdhnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhuth dprhgtphhtthhopehinhhtvghrnhgrlhhssehlihhsthhsrdhphhhprdhnvght X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 7FCAC780067; Tue, 10 Sep 2024 13:59:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 Date: Tue, 10 Sep 2024 19:59:11 +0200 Cc: internals@lists.php.net Message-ID: <3f179c5f-7b4a-4191-9bff-e12b45ccccac@app.fastmail.com> In-Reply-To: References: <2716f729-4008-4f75-8412-861d8960b746@app.fastmail.com> Subject: Re: [PHP-DEV] function autoloading v4 RFC Content-Type: multipart/alternative; boundary=22f50e14b770439e9475c1672d190349 From: rob@bottled.codes ("Rob Landers") --22f50e14b770439e9475c1672d190349 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Sep 10, 2024, at 15:28, Gina P. Banyard wrote: > On Tuesday, 3 September 2024 at 23:44, Rob Landers = wrote: >> On Thu, Aug 15, 2024, at 17:22, Rob Landers wrote: >>> Hello internals, >>>=20 >>> I've decided to attempt an RFC for function autoloading. After readi= ng hundreds of ancient (and recent) emails relating to the topic along w= ith several abandoned RFCs from the past, and after much review, I've de= cided to put forth a variation of a previous RFC, as it seemed the least= ambitious and the most likely to work: >>>=20 >>> https://wiki.php.net/rfc/function_autoloading4 >>>=20 >>> Please let me know what you think. An implementation should be along= before opening it for a vote (now that I realize how important that is). >>>=20 >>> =E2=80=94 Rob >>=20 >> Hello internals, >>=20 >> I've updated the RFC text and clarified some language (hopefully) whi= le also addressing a number of concerns. >> 1. I've removed the BC break=E2=80=94the 'type' of the autoloadee w= ill not be passed to the autoloader. This can allow someone to use spl_a= utoload for function autoloading if they so desire. >> 2. I've removed artificial restrictions on the constants in which al= l functions that take them can accept both at the same time and behave a= ppropriately. >> 3. I've performed multiple benchmarks on several projects (WordPress= , Symfony, and others from techempower) and couldn't detect a statistica= lly significant performance difference with this feature in multiple con= figurations. >> 4. Some simplified aspects of Gina's implementation for core autoloa= ding were integrated into the patch. However, I see that RFC as a genera= l refactoring of the API more than function autoloading. This RFC is str= ictly about function autoloading while being very conservative with the = autoloading API. >> While minor issues in the PR are still being worked on, I plan to ope= n the vote next Wednesday, September 11th 2024, barring any significant = pushback or objections >=20 > What is the rush in wanting to put this RFC to a vote *now*? > You know that I was on holidays for 2 weeks and that I am open to coll= aborate, as I replied to you off list. > What benefit does opening the vote on the RFC give? > You are giving busy work for RFC voters when there is another related = RFC and there is still a whole year to work on it. > I'd expect this behaviour if this were June, not September.... >=20 > I can understand wanting to get stuff moving quickly, but this is not = how things work, adding support for something in a jank way is not bette= r than not adding it at all. > I still do not believe that shoehorning more stuff into the current SP= L mechnaism is good, I do not think using a bitflag for setting the auto= loaders is a good nor sensible API (because if you class and function au= toloader behave the same I have questions). > Reading the RFC I have no idea how you are tackling the global namespa= ce fallback, nor how you are going to prevent the lookup happening multi= ple times. >=20 > As such in the current state I will vote against it, and be annoyed th= at you are making me do busy work. >=20 >=20 > Best regards, >=20 > Gina P. Banyard Hi Gina & Jordi, I believe there has been some confusion, so I'm postponing the vote inde= finitely. From the beginning, I have stated that I don't see these two RFCs as com= peting or mutually exclusive. The core autoloading RFC (which I'd still = love to collaborate on) seems to be about > The proposal consists of adding a better designed class autoloading me= chanism and a new function autoloading mechanism, and ***aliasing the ex= isting autoload functions to the new versions*.** (emphasis mine) From my perspective, function autoloading is a secondary= aspect of the core autoloading RFC, even if it is the main motivation. = The new core autoloading API includes function autoloading, but separati= ng it wouldn't change the proposed API much, if at all, and would remove= the need to introduce function autoloading as a "new" feature. Here's a summary of potential outcomes with what we have today: | core autoload | autoload v4 | function autoloading | | success | success | success | | fail | success | success | | success | fail | success | | fail | fail | fail | If this RFC isn't put towards a vote, there's only a 50% chance of havin= g function autoloading in some form. However, if it is, there is a 75% c= hance. So, to maximize our chances of achieving function autoloading (my= primary goal atm), it makes sense to follow the RFC process and put it = to a vote. This RFC tries really hard to "be as PHP as possible" and fit= in with the legacy API it is surrounded by. It isn't trying to be moder= n, by any stretch of the imagination; rather, it is trying to look as th= ough it belongs there from the beginning. If this RFC succeeds, it will simplify the design of core autoloading, a= llowing us to focus expressly on the API, which I believe would improve = its chances of success. This aligns with what I shared with Gina off-lis= t 18 days ago=E2=80=94there's no rush, but there's also no reason to del= ay (except for this discussion, which can hopefully be productive). If this RFC fails, nothing has to be done for core autoloading, it can r= emain as-is and try to reintroduce function autoloading. In either case,= I believe there may be valuable feedback from voters that would be miss= ing in this discussion=E2=80=94there almost always is, from seeing other= RFCs pass/fail. Maybe I am looking at this all wrong. I tend to look at problems differe= ntly than other people and 'just solve them' in as pragmatic a manner th= at is possible. Sometimes, this means I end up doing the wrong thing, bu= t I hope that isn't the case here, though it seems like it might be. I'm= not trying to be challenging or waste people's time; just following a p= rocess and trying to be logical. Perhaps it is more logical to wait and see how core autoloading plays ou= t? =E2=80=94 Rob --22f50e14b770439e9475c1672d190349 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 10,= 2024, at 15:28, Gina P. Banyard wrote:
On Tuesd= ay, 3 September 2024 at 23:44, Rob Landers <rob@bottled.codes> wro= te:
On Thu, Aug 15, 2024, at 17:22, Rob Landers wrote:
Hello in= ternals,

I've decided to attem= pt an RFC for function autoloading. After reading hundreds of ancient (a= nd recent) emails relating to the topic along with several abandoned RFC= s from the past, and after much review, I've decided to put forth a vari= ation of a previous RFC, as it seemed the least ambitious and the most l= ikely to work:


Please let me know what you think. An= implementation should be along before opening it for a vote (now that I= realize how important that is).

=E2=80=94 Rob

Hello internals,

I'= ve updated the RFC text and clarified some language (hopefully) while al= so addressing a number of concerns.
  1.  = I've removed the BC break=E2=80=94the 'type' of the autoloadee will not = be passed to the autoloader. This can allow someone to use spl_autoload = for function autoloading if they so desire.
  2. I'v= e removed artificial restrictions on the constants in which all function= s that take them can accept both at the same time and behave appropriate= ly.
  3. I've performed multiple benchmarks on sever= al projects (WordPress, Symfony, and others from techempower) and couldn= 't detect a statistically significant performance difference with this f= eature in multiple configurations.
  4. Some simplif= ied aspects of Gina's implementation for core autoloading were integrate= d into the patch. However, I see that RFC as a general refactoring of th= e API more than function autoloading. This RFC is strictly about functio= n autoloading while being very conservative with the autoloading API.
While minor issues in the PR are still being work= ed on, I plan to open the vote next Wednesday, September 11th 2024, barr= ing any significant pushback or objections

What is the rush in wanting to put this RFC to a vote= *now*?
You know th= at I was on holidays for 2 weeks and that I am open to collaborate, as I= replied to you off list.
What benefit does opening the vote on the RFC give?
You are giving busy work for RFC= voters when there is another related RFC and there is still a whole yea= r to work on it.
I'= d expect this behaviour if this were June, not September....

I can understand wanting to get stuff moving qui= ckly, but this is not how things work, adding support for something in a= jank way is not better than not adding it at all.
I still do not believe that shoehorning m= ore stuff into the current SPL mechnaism is good, I do not think using a= bitflag for setting the autoloaders is a good nor sensible API (because= if you class and function autoloader behave the same I have questions).=
Reading the RFC I = have no idea how you are tackling the global namespace fallback, nor how= you are going to prevent the lookup happening multiple times.
=

As such in the current state I will vote again= st it, and be annoyed that you are making me do busy work.


Best re= gards,

<= span class=3D"font" style=3D"font-family:Verdana, sans-serif;">Gina P. B= anyard
=
Hi Gina & Jordi,

I belie= ve there has been some confusion, so I'm postponing the vote indefinitel= y.

From the beginning, I have stated that I= don't see these two RFCs as competing or mutually exclusive. The core a= utoloading RFC (which I'd still love to collaborate on) seems to be abou= t

The proposal co= nsists of adding a better designed class autoloading mechanism and a new= function autoloading mechanism, and **aliasing the existing autoload= functions to the new versions.**

(emphasis mine) From my perspective, function autoloading is a s= econdary aspect of the core autoloading RFC, even if it is the main moti= vation. The new core autoloading API includes function autoloading, but = separating it wouldn't change the proposed API much, if at all, and woul= d remove the need to introduce function autoloading as a "new" feature.<= br>

Here's a summary of potential outcomes with= what we have today:

| core auto= load | autoload v4 | function autoloading |
| success       | success     | s= uccess              |
| fail          | success = ;    | success             = |
| success       |= fail        | success        &n= bsp;     |
| fail   =       | fail        | fail  &nb= sp;              |

If this RFC isn't put towards a vote, there's only a 5= 0% chance of having function autoloading in some form. However, if it is= , there is a 75% chance. So, to maximize our chances of achieving functi= on autoloading (my primary goal atm), it makes sense to follow the RFC p= rocess and put it to a vote. This RFC tries really hard to "be as PHP as= possible" and fit in with the legacy API it is surrounded by. It isn't = trying to be modern, by any stretch of the imagination; rather, it is tr= ying to look as though it belongs there from the beginning.

If this RFC succeeds, it will simplify the design of co= re autoloading, allowing us to focus expressly on the API, which I belie= ve would improve its chances of success. This aligns with what I shared = with Gina off-list 18 days ago=E2=80=94there's no rush, but there's also= no reason to delay (except for this discussion, which can hopefully be = productive).

If this RFC fails, nothing has= to be done for core autoloading, it can remain as-is and try to reintro= duce function autoloading. In either case, I believe there may be valuab= le feedback from voters that would be missing in this discussion=E2=80=94= there almost always is, from seeing other RFCs pass/fail.

=
Maybe I am looking at this all wrong. I tend to look at probl= ems differently than other people and 'just solve them' in as pragmatic = a manner that is possible. Sometimes, this means I end up doing the wron= g thing, but I hope that isn't the case here, though it seems like it mi= ght be. I'm not trying to be challenging or waste people's time; just fo= llowing a process and trying to be logical.

Perhaps it is more logical to wait and see how core autoloading plays o= ut?

=E2=80=94 Rob
= --22f50e14b770439e9475c1672d190349--