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
