Re: function autoloading v4 RFC

On Tue, Aug 20, 2024, at 18:07, Rob Landers wrote: > On Tue, Aug 20, 2024, at 08:50, Rowan Tommins [IMSoP] wrote: >> >> >> On 20 August 2024 00:21:22 BST, Rob Landers <rob@bottled.codes> wrote: >> > >> >I assume you are worried about something like this passing test? >> > >> >--TEST-- >> >show called only once >> >--FILE-- >> ><?php >> > >> >namespace test; >> > >> >spl_autoload_register(function($name) { >> > echo "name=$name\n"; >> >}, true, false, SPL_AUTOLOAD_FUNCTION); >> > >> >echo strlen('foo'); >> >echo strlen('bar'); >> >echo strlen('baz'); >> >?> >> >--EXPECT-- >> >name=test\strlen >> >333 >> > >> >In my RFC, I mention it is called exactly once. >> >> >> I haven't looked at the PR, only the RFC, and I did not see this very important detail >> explained anywhere. The only thing I can see is this rather ambiguous sentence: >> >> > The function autoloader will not be called again. >> >> That could mean not called again for the current call (compared with proposals that call it >> a second time with the unequalled name); it could mean not called again for the current line of code >> (based on the current caching behaviour); or never called again for that combination of namespace >> and name; or possibly, never called again for that combination of namespace, name, and callback >> function. >> >> That's not a small detail of the implementation, it's a really fundamental >> difference from previous proposals. >> >> So I would like to repeat my first response to your RFC: that it should sound more time >> explaining your approach to the multiple lookup problem. >> >> Regards, >> Rowan Tommins >> [IMSoP] >> > > Thanks Rowan, > > That's a fair critique. > > I expect some of the wording will be more clear once I write out the documentation -- even if > it isn't used directly, I tend to write out documentation to force myself to reconcile the code > with the plan, find logic bugs, perform larger scale tests, and create tests to verify assertions in > the documentation. From there, I'll update the plan or code to get everything to match and > spend some time on clarity. It's the hardest part, IMHO, as it requires diligently ensuring > everything is correct. In other words, writing the documentation makes it feel like a "real > thing" and it triggers what small amount of perfectionism I have. > > — Rob I have an experimental library that I use for testing these kinds of things. There are aspects of it that I could work with to make use of function autoloading. Thus, I did so and benchmarked the performance of unit tests. The unit testing library makes a ton of "unqualified function calls". I spent some time working on two autoloaders: 1. A naive autoloader: parses out the file to load, checks if it exists, and then requires the file. 2. An optimized autoloader: only cares about the namespace it has registered. All others are an instant return. In the "vanilla" case, I was mostly concerned with variation. I wanted a statistically significant result, so once I got my system into a stable state and I was no longer seeing any variance, I started benchmarking. For the naive autoloader, I saw a performance degradation of about 6% and lots of variability. This is probably due to the "file_exists" check being done every time an unqualified name was called. However, for the optimized autoloader, I ended up with less variability (🤔) than the vanilla approach and absolutely no measurable performance degradation. Now, time to try this on a larger scale... WordPress. It's pretty much the only large codebase I know of that makes use of tons of functions. — Rob