[RFC] New core autoloading mechanism with support for function autoloading

I don’t like the proposed function names: autoload_register_class to me reads like “register this class for autoloading”. If I observe the intended meaning correctly, it should be called “register_class_autoloader”. Same for autoload_register_function - better name would be “register_function_autoloader”. Other functions should be renamed accordingly. Function names should read like a sentence, like a command. On Mon 10. 4. 2023 at 14:17, G. P. B. <george.banyard@gmail.com> wrote:

On 10.04.2023 14:17, G. P. B. wrote:

I think it would make a lot of sense to have one function for all kind of features, but the user should define which ones. For example: Loader::register(callable $callback, int $type, bool $prepend = false): void; then Loader::register($callback, Loader::TYPE_CLASS | Loader::TYPE_FUNCTION); Or sth like that. My 2c.

Hello George, I'm not sure I'm 100% correct but I think that this RFC still allows to call different functions for the same code, just not in the same run. Consider this pseudocode: //- funcs.php namespace My; function myfunc(...) { ... } function array_map(...) { ... } //- code1.php namespace My; myfunc(1); // autoload triggered // bonus points if it's a different file or some obscure method array_map(strlen(...), []); // My\array_map //- code2.php namespace My; // no prior autoload array_map(strlen(...), []); // global array_map And if I understand the current order of execution correctly, here is a more extreme example: //- moreextreme.php namespace My; if (some_random()) { array_map('My\myfunc', []); // global array_map } else { array_map(myfunc(...), []); // My\array_map }

Hi George and Dan, pon., 10 kwi 2023 o 14:17 G. P. B. <george.banyard@gmail.com> napisał(a):

Thanks for bringing this up, I like the RFC and addressing function autoload. Can we improve the RFC with a short description of issues on SPL autoload this RFC tries to address? It is mentioned in at least two places that this proposal addresses some minor issues with SPL autoload. However, I think it'd be worth mentioning them in RFC so the reader can get a complete picture of what the RFC tries to address besides adding new features like function autoload. Cheers, Michał Marcin Brzuchalski

On 10 April 2023 13:17:04 BST, "G. P. B." <george.banyard@gmail.com> wrote:

Hi! Thanks both for tackling this, I know function autoloading has long been on a lot of people's wish lists. A few thoughts:

The lookup pinning seems like the right way to optimise the implementation, but I don't think it should be visible to user code like this - a lookup for "strlen" in namespace "Foo" is not the same as defining the function "Foo\strlen". Consider this code: namespace Bar { if ( function_exists('Foo\strlen') ) { \Foo\strlen('hello'); } } namespace Foo { strlen('hello'); // triggers name pinning } namespace Bar { if ( function_exists('Foo\strlen') ) { \Foo\strlen('hello'); } } If I'm reading the RFC correctly, the second function_exists will return true. I'm less clear if the call to \Foo\strlen will actually succeed - if it gives "undefined function", then function_exists is clearly broken; if it calls the global strlen(), that's a very surprising side effect. For bonus points, the call to strlen that triggers pinning could be inside an autoloader, making even the first function_exists call return true. Similarly, I think it should be possible to "unpin" a function lookup with a later definition, even if no autoloading would be triggered. That is, this should not be a duplicate definition error: namespace Foo; if ( strlen('magic') != 42 ) { function strlen($string) { /* ... */ } }

This isn't actually true: classes, interfaces, traits, and enums all share a symbol table, and thus an autoloader. I don't know of a good name for this symbol table, though. Regarding the API, would it be possible to take advantage of nearly all autoloaders only being interested in particular namespace prefixes? Currently, every registered autoloader is run for every lookup, and most immediately check the input for one or two prefixes, and return early if not matched. I suspect this design is largely because autoloading came before namespaces, so the definition of "prefix" wasn't well-defined, but going in and out of userland callbacks like this is presumably rather inefficient. Perhaps the "register" functions should take an optional list of namespace prefixes, so that the core implementation can do the string comparison, and only despatch to the userland code if the requested class/function name matches. Thanks again for working on this! Regards,

At a high level: +1, would vote for again (I think I voted for this last time it came up...) Initial thoughts, mostly based on replies so far: 1/ There's certainly some bike-shedding for the names to do. Good points have already been made and I won't belabor them. 2/ I'm unconcerned by the edge case brought up about load ordering as I feel that having multiple definitions of a single function name in an autoload friendly codebase grouped in files which permit this kind of shenanigans is a technical possibility, but a practical absurdity. Nobody should be designing traps like that. 3/ Pinning concerns me a little, and we should certainly build some strong unittests to validate behavior here, but I'm confident that can be resolved during implementation. 4/ If nothing else, I just look forward to gaining consistency here. autoloading being exclusive to classes has long annoyed me, just not quite to the point of action. :) -Sara

On 10/04/2023 14:17, G. P. B. wrote:

I fully support this endeavour: I've wanted this for such a long time now. A while ago I was pressured into splitting two of my libraries that provided both function and class/method calls, increasing my maintenance workload. This would allow me to combine them again. Looking at all the points that have already been raised, I think Sara sums up well. I also like Rowan's suggestion of a list of namespace prefixes. In particular, you're already considering the use of maps for even better performance, and Constant and Stream autoloading, as possible future enhancements. Constants in particular is something I'd find particularly useful; and my only concern with this is the increased number of functions compared with a single function that accepts a Type argument (as Aleksander suggests). A couple of general questions: Are there any core functions that should never by overloaded (function_exists() perhaps)? We have the special constants like \MyNamespace\MyClass::class. Would you envisage (or is there value in) equivalent constants like \MyNamespace\MyFunction::function? If there is value, how would that tie in with referencing them as Callables in callback functions?

On Monday 10 April 2023 14:17:04 (+02:00), G. P. B. wrote:

Core

Thanks for taking the time for this, I only quickly skimmed over it, an insightful reading already. What I wondered about and which made me writing a reply on the list is in retrospect of the times class autoloading came in, which is also closer to the time when namespaces were introduced. It was the latter which brought us `class_alias()` [0] and I've used it often in code migrations (is 8.3 the new 5.3? would be easy to remember.). So I'd love to see some commentary on a `function_alias()` if now function autoloading is considered to come in, as I can imagine this has similar effects for how you'd like to namespace PHP code with the new, better functionality of function autoloading and access to an alias table from PHP "userspace" I'd consider helpful then. Best, -- hakre [0]: https://www.php.net/class_alias

Hello George, Dan and I would like to propose a new core autoloading mechanism that fixes

Thanks to you and Dan for the RFC. I have two main questions about this: 1. What's the performance hit? 2. If the perf hit is measurable, is function autoloading worth it? aka what problem does it address? About the perf hit, I see that you put a lot of thought into minimizing it and that's sound. The way I see this feature be spread to userland is via composer of course. I foresee that composer will add a way for packages to declare function autoloading. This means that every application that uses composer will be impacted by the perf overhead eventually (aka the case of "programs that do not have a function autoloader registered" mentioned in the RFC won't happen in practice.) In e.g. https://github.com/php/php-src/pull/6627#issuecomment-773922448, Dmitry explains that adding inheritance cache to PHP provided a 8% perf benefit when running a demo app. I would like to see a similar benchmark with function autoloading enabled. https://github.com/phpbenchmarks/ provides several demo apps so it could be a nice playground for running this. Then, depending on the resulting numbers, I anticipate several possible outcomes: - if the impact is really low, then all is fine and we can keep things as is; - otherwise, I'm also interested in this idea to scope function autoloading per namespace, so that the engine can filter ahead of calling any userland autoloaders; - if the overhead is still significant, could another idea be to load functions per namespace, where the engine would ensure to call function autoloaders only once per namespace? Even with the current proposal, I can easily anticipate that a common practice for package authors could be to put all functions in one file, and register a function autoloader that would require that file for any of the functions in it. Loading per namespace would fit this loading strategy. But before exploring this idea, let's get some numbers about the performance of the previous approaches. Then comes my second main question: what does this solve? To me, class autoloading is a performance feature. If we didn't care about performance, we would be fine with eagerly loading a bunch of classes as e.g. Java does. But because we run PHP mainly in short-lived request/response loops, loading just the few classes we need to serve a specific request provides the best performance. In recent versions of PHP, we may question this practice, since we now have a crazy good opcache. Of course, I'm not suggesting removing autoloading for classes. But if we do have that crazy good opcache, what do we need function autoloading for? The current way for package authors to declare classes is via composer "files <https://getcomposer.org/doc/04-schema.md#files>" entry. One could argue in the past that this adds needless "require" on the hotpath. But if they cost nothing thanks to recent opcache improvements, we don't need to care, do we? At least, we need to compare both approaches, because if the main argument for adding function autoloading is lazy-loading of function implementations, then it must be faster than eager-loading. This circles back to my previous question, so we'd really need a thorough perf analysis IMHO. Nicolas

Hi, 1. The proposed modification of `function_exists()` will break existing code: <?php namespace foo; if (!function_exists(__NAMESPACE__.'\\bar')) { function bar() { // .... } } ?> as soon as a `bar()` function is defined in global scope, with no obvious hint why it suddenly broke. You should either (from my increasing order of preference): * acknowledge it in the “Backward Incompatible Changes” section; * default the $autoload extra parameter to `false`; * keep the current semantics, that using a namespaced or qualified function name, (including a function name given as string, which is implicitly fully qualified), doesn’t fall back to the global scope, — even when a previous use of the same function name did trigger the fall back, see: https://3v4l.org/mnVWO (Independently of any mechanism introduced to avoid to repeatedly trigger the function autoloader.) 2. If you add function autoloading, you ought to support constant autoloading as well, of course. —Claude

On Mon, 10 Apr 2023, G. P. B. wrote:

I find the chosen names (_register_class, _unregiester_class, _call_class, _list_class, _register_function, _unregister_function, _call_function, and _list_function) not very clear. From reading just their names, I would have no idea of what they would do as they don't read like an instruction. You're not registering a class or function, you're registering a *handler* for resolving the class or function name being passed in. | If a function named strlen exists in the namespace bar PHP would use | that, otherwise PHP would 'fallback' to the strlen() function in the | global namespace. ... | | When code tries to call a function that doesn't currently exist in the | current namespace, the function autoloader mechanism will call the | registered function autoloaders once with the fully namespaced | function name. Doesn't that mean that the autoloader would be called for (almost) every built-in function? That sounds like a large performance hit. Even if done only once per ... per what exactly? Source location? Fully qualified unction name? Where is this information stored? Your line on pinning is a little vague on this. | The position of this RFC is that this behaviour is correct both from a | performance point-of-view I would like to see that backed that up with hard data. | though arguably from other positions it might be less correct. Which positions would that be? | The current RFC as proposed has a large BC break for the code: … | Which needs to be thought about. Can you clarify what the output would be? I'm expecting: bool(false) int(1) bool(true) bool(true) int(42) Which is already confusing, IMO? Or does the first function_exists also call the autoloader? Have you seen this pattern used anywhere? If it is, then this can't / shouldn't be broken in PHP 8.3, but rather earlist in 9.0. | Accuracy of the naming I think that the phrasing in there indicates that there is already a scope for improving on the (IMO) less than stellar proposed naming of the functions that register autoload handlers. And perhaps using *type* in the name is the best way forwards? cheers, Derick