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. > > - 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. > > - 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. > > - 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. > > - 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
