Update of "rfc:function_autoloading"
Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Artifact ID: | 1803896e226c2c985ce2bf23a778d6cb95df0d7f |
---|---|
Page Name: | rfc:function_autoloading |
Date: | 2014-09-04 22:52:58 |
Original User: | mario |
Mimetype: | text/x-markdown |
Parent: | 4b15e9a39c6df7d6d9dfdb7ba7c2a848bbdaaa3d (diff) |
Next | e24b51235731f910a58e0ae74f6b9b3890ac7f09 |
Function autoloading
PHP is a hybrid language. It however unevenly implements autoloading for classes only as of now. There are long-standing feature requests for supporting it with all language symbols. A more recent attempt to bring some systematization here was:
See https://wiki.php.net/rfc/function_autoloading
The ensuing php-dev discussion wasn't overly constructive. (Fatal errors provide a higher performance than autoloading a function). Backhandedly however to prevent functions becoming first class language constructs, due to them implying an unfavored coding paradigm.
Meanwhile PHP 5.6 introduced use function
imports - which however are aliases only, thus magnifying the dichotomy only further.
Why is it in shared.phar ?
With shared.phar
revisiting the big picture was a design goal, not repeating what's already there.
- Function autoloading here is a proof-of-concept mostly.
- Requires little additional effort for the autoloader.
- And implementing it in the map generator was a trivial by-product of doing things properly anyway.
It still be be optionalized however, when unneeded.
How can I use it now?
See the attached example, which shows the common class::__callStatic()
workaround for current PHP versions. While such a class wrapper bemusingly gets autoloaded itself, it's probably only suitable for e.g. application-level plugin hook schemes.
The lack of core language support makes it unsuitable for autoloading namespaced functions. It can just shoehorn in global functions easily, or else required x::{"pkg\\bundle\\func"}()
invocations.