On Tue, Aug 20, 2024, 4:56 PM Rob Landers <rob@bottled.codes> wrote:
>
>
> 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.
>
>
Not to sound flippant, but you do realize that composer does a lot of
optimizations just like this, right?
PSR-4 exists in large part due to a realization that better optimizations
were possible when you mapped namespaces to source code directories. And
Composer takes it a step further when you have it create an optimized
loader, because then it maps classes directly to the files that provide
them, preventing I/O up to the point that a require is performed.
My point is that this is why folks have been suggesting that this is a
solved problem. Globally qualify functions, and you get immediate
performance benefits due to removal of the need to look up via the
namespace first. Most CS tools will even add the imports or qualifiers for
you, and you can have your IDE or editor configured to do it as well.
I wouldn't spend your time on this facet.
> 1.
>
> 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
>
