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

On Mon, 10 Apr 2023, G. P. B. wrote: > Hello Internals, > > Dan and I would like to propose a new core autoloading mechanism that fixes > some minor design issues with the current class autoloading mechanism and > introduce a brand-new function autoloading mechanism: > https://wiki.php.net/rfc/core-autoloading > > The existing SPL autoloading functions would become aliases to the new Core > ones and will continue to work without any migrations needing to be > performed. > > Hope to hear your opinions about this! 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