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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
