On Thu, Aug 15, 2024, at 20:40, Rowan Tommins [IMSoP] wrote:
On 15/08/2024 16: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
Hi Rob,
While brevity can sometimes be a virtue, I feel like there’s a lot left to the reader’s interpretation here.
Specifically, one of the main issues that has come up in previous discussions of the topic is the behaviour of unqualified function names, which check the current namespace first, then fall back to global scope. Your RFC implies an approach to this, but doesn’t actually spell it out, nor discuss its pros and cons.
It doesn’t go too much into details here on purpose, especially since there was some recent discussion on changing the order. That being said, while writing the reply below, I realized it simply wasn’t clear enough. I’ve updated the RFC to be more clear, in regards to the current behavior.
The fully qualified case is straight-forward: the autoloader is called, and if still not defined, an error is thrown. But for the unqualified case, there are multiple scenarios, and you only give the behaviour for one of them:
To fill in your chart:
Defined in current namespace? | Defined in global namespace? | Proposed behaviour
------------------------------±-----------------------------±-------------------------------------
No | No | Prefixed name
No | Yes | Prefixed name
Yes | No | No change
Yes | Yes | No change
The third and fourth cases (where the function exists in the current namespace) are straight-forward, although it wouldn’t hurt to spell them out: presumably, the namespaced function is used as now, so no autoloading is needed.
The complex case has always been the second one: the function doesn’t exist in the current namespace, but does exist in the global namespace. (Or, an autoloader defines it in the global namespace.)
This should have the same behavior as in the class autoloader. In my attempt to be vague (in case the loading order is changed, which I assumed would affect class autoloading as well), I wasn’t very clear on this. Meaning if you create a class called “Fiber” and a function called “strlen” in the current namespace, in unloaded files, an autoloader should be given the opportunity to load them.
I should also probably define some vocabulary so this is all less confusing. and Done.
In concrete terms, what does this code output:
spl_autoload_register( function($function, $type) { echo “$function…”; }, type:SPL_AUTOLOAD_FUNCTION);
namespace Foo {
foreach ([‘hello’, ‘goodbye’] as $word) {
echo strlen($word), ‘;’;
}
}
a) “Foo\strlen…5;Foo\strlen…7;” (the autoloader is called every time the function is encountered)
b) “Foo\strlen…5;7;” (the autoloader is called once, then somehow marked not to run again for this name
c) “5;7;” (the autoloader is never run for this code)
I believe the “most correct” answer is (a) – and is what the current class autoloader does as well. Option (b) would make it impossible to do any kind of dynamic code generation or old-fashioned file-based deployments.
namespace global {
spl_autoload_register(function ($function) {
echo "$function...";
});
}
namespace Foo {
foreach (['hello', 'goodbye'] as $word) {
if (!class_exists(Fiber::class)) {
echo "Test...";
}
}
}
Since I foresee (based on previous conversations) about people being worried about performance:
I think this is best left to autoloader authors to manage. If there isn’t a function autoloader, then there won’t be any performance impact (or at least, minimal). However, if there is one, the author can take into account how their codebase works. For example, I highly suspect FIG will create a PSR for this (eventually), based on how they expect things to work. I suspect a project like WordPress could make use of it and implement things how they expect things to work, etc.
For the case where you have a file full of unqualified strlen()'s, the autoloader author could create an option “do not shadow global functions” where it just returns immediately for built-in functions and doesn’t even try autoloading (I also suspect there will be someone who code-golfs this to death so this check is extremely efficient). Is there a performance impact there? Probably not as big as you’d think – and there already is a performance impact by using unqualified global functions (as shown in a recent proposal to change the order). So, if you are doing that already; you likely don’t care about performance anyway.
But I’m going to reserve any serious discussions about performance for when I have an actual implementation to play with (hopefully a PoC this weekend).
Note that there is an open RFC implementing option (b) by Gina and Dan here: https://wiki.php.net/rfc/core-autoloading Last I heard, Gina was still hoping to get back to it.
I went looking for this (I had sworn I had seen it last year), but unfortunately, I did not find it while searching the RFCs for prior work. I had thought it abandoned so I was looking in the wrong place. This RFC does not conflict with that RFC, if Gina/Dan were to pick it back up again. I may borrow the function_exists() change, which I just updated the RFC to do.
On a different note, there is no mention of autoloading namespaced constants in this RFC, unlike in some previous proposals. Is this a conscious decision to leave them out of scope, or an oversight?
I’m leaving them out on purpose to keep the scope tight. I’ve got a whole year ahead of me.
Regards,
--
Rowan Tommins
[IMSoP]
— Rob
) than the vanilla approach and absolutely no measurable performance degradation.