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

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

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.

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? -- Mark Baker