> Unfortunately, function name resolution has this quirk that class name
resolution doesn't, so something's got to give.
I suppose.
Well, then, how about making the feature work consistently for all
functions, by coupling it directly to the "use function" statement?
In other words, the feature changes from being strictly about auto-loading
functions, to instead resolving an imported function - so it would be
triggered by the "use function" statement only, rather than by the use of
the function, and the resolved function pertains only to the scope of the
file.
A function resolver would simply need to return a callable:
register_function_resolver(function ($name) {
if ($name === "html") {
return function ($str) {
return htmlspecialchars($str, ENT_HTML5);
};
}
if (substr($name, 0, 5) === "iter\\") {
require_once VENDOR_PATH."/nikic/iter/src/bootstrap.php";
return $name;
}
});
This mechanism is probably a lot easier to explain and understand - and
works equally for global or namespaced functions.
It also lets you potentially do other weird shit, like overriding
var_dump() or hooking into certain function calls - which could enable you
to do a bunch of evil, but I'm not really big on complicating features
solely to keep users from doing harm; simpler language features tend to
allow you to do more stuff - good or evil.
Likely the 99% use-case is simply for Composer to bootstrap your packages
for you, and this feature will permit you to do that.
Okay, so it doesn't deal with namespaced constants, and maybe this is me
being opinionated, but who's going to import constants one by one?
Constants are usually better off grouped together in a class. Although I
don't suppose there's any reason this concept couldn't be expanded to work
for constants as well, for completeness at least - though I have doubts
that very many people would care...
Anyways, just spitballing here :-)
On Mon, Aug 8, 2016 at 7:54 PM, Rowan Collins <rowan.coll...@gmail.com>
wrote:
> On 08/08/2016 18:03, Levi Morrison wrote:
>
>> If not, I don't see why we ever need to be able to autoload global
>> functions. "You want autoloading? Put it in a namespace." Like I
>> say, that leaves the very small edge case of a single namespace
>> spanning multiple files, and an autoloader implementation able to
>> include one of them when a function is called from another.
>>
>>
>> I'm not sure why you would think a single namespace spanning multiple
>> files is a "very small edge case". I disagree. Here are some libraries I
>> am aware of *off the top of my head* that use functions the same
>> namespace across multiple files:
>>
>> * https://github.com/nikic/iter
>> * https://github.com/lstrojny/functional-php
>>
>> As well as several of my personal projects. I do not think this is a
>> "very small edge case."
>>
>
> The "iter" example looks a long way from being autoloadable whatever we
> supported, but the example of one-function-per-file is definitely relevant,
> so I stand corrected.
>
> After a bit of clicking, I even managed to find a line which would fail to
> autoload under the proposed limitation:
>
> https://github.com/lstrojny/functional-php/blob/master/src/
> Functional/CompareObjectHashOn.php
>
> > return compare_on($comparison, $keyFunction);
>
> Although interestingly, at the top of the file there is a (technically
> unnecessary) "use function Functional\compose;" If there was a "use
> function Functional\compare_on;" as well, we'd be fine. (The function name
> would then become qualified at compile time and trigger autoloading at run
> time.)
>
>
> On 08/08/2016 18:06, Rasmus Schultz wrote:
> > Unless there's a demonstrated, critical performance issue with
> > auto-loading of global functions, please, let's not cripple this feature
> > with inconsistencies from the get-go!
>
> Sure, we could try to measure it, but remember that it's not just the
> engine code that has the extra cost, it will actually call a userland
> function every time you use a global function from inside a namespace if
> you don't add a leading "\". That userland function will probably do a
> bunch of string comparisons before deciding it's not interested, and may
> even try to stat a file or two. Those are really expensive operations, so I
> think it's a long way from "micro-optimisation".
>
> Unfortunately, function name resolution has this quirk that class name
> resolution doesn't, so something's got to give.
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
