Re: function autoloading v4 RFC

On Tue, Sep 10, 2024, at 15:28, Gina P. Banyard wrote: > On Tuesday, 3 September 2024 at 23:44, Rob Landers <rob@bottled.codes> wrote: >> On Thu, Aug 15, 2024, at 17:22, Rob Landers wrote: >>> Hello internals, >>> >>> I've decided to attempt an RFC for function autoloading. After reading hundreds of >>> ancient (and recent) emails relating to the topic along with several abandoned RFCs from the past, >>> and after much review, I've decided to put forth a variation of a previous RFC, as it seemed >>> the least ambitious and the most likely to work: >>> >>> https://wiki.php.net/rfc/function_autoloading4 >>> >>> 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). >>> >>> — Rob >> >> Hello internals, >> >> I've updated the RFC text and clarified some language (hopefully) while also >> addressing a number of concerns. >> 1. I've removed the BC break—the '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've removed artificial restrictions on the constants in which all functions that >> take them can accept both at the same time and behave appropriately. >> 3. I've performed multiple benchmarks on several projects (WordPress, Symfony, and >> others from techempower) and couldn't detect a statistically significant performance difference >> with this feature in multiple configurations. >> 4. Some simplified aspects of Gina's implementation for core autoloading were >> integrated into the patch. However, I see that RFC as a general refactoring of the API more than >> function autoloading. This RFC is strictly 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 open the vote next >> Wednesday, September 11th 2024, barring any significant pushback or objections > > 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 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 year to work on it. > I'd expect this behaviour if this were June, not September.... > > 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 better than not adding it at all. > I still do not believe that shoehorning more 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 against it, and be annoyed that you are making me do > busy work. > > > Best regards, > > Gina P. Banyard Hi Gina & Jordi, I believe there has been some confusion, so I'm postponing the vote indefinitely. From the beginning, I have stated that I don't see these two RFCs as competing 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 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 secondary aspect of the core autoloading RFC, even if it is the main motivation. The new core autoloading API includes function autoloading, but separating 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 having function autoloading in some form. However, if it is, there is a 75% chance. 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 modern, by any stretch of the imagination; rather, it is trying to look as though it belongs there from the beginning. If this RFC succeeds, it will simplify the design of core autoloading, allowing 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-list 18 days ago—there'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 reintroduce function autoloading. In either case, I believe there may be valuable feedback from voters that would be missing in this discussion—there almost always is, from seeing other RFCs pass/fail. Maybe I am looking at this all wrong. I tend to look at problems differently than other people and 'just solve them' in as pragmatic a manner that is possible. Sometimes, this means I end up doing the wrong thing, but 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 process and trying to be logical. Perhaps it is more logical to wait and see how core autoloading plays out? — Rob