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
