On Tue, Aug 9, 2016 at 12:04 AM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> I don't quite follow what you're suggesting here. When does this "function
> resolver" get called?
I'm suggesting the use-statement be the trigger, rather than actually
calling the function.
In other words, calls to substr() does not trigger the resolve - a
statement like "use function substr" on the other hand, does.
> Why does returning a callable rather than just
> defining the function help with the problems we've been discussing?
For some reason, at the time, I thought, this way the function would
indicate whether it resolved a request for "foo\bar" as "foo\bar" or
"bar", but that's probably false... likely the registered function
would get called twice by the engine, first trying for the namespaced,
then if that doesn't resolve, for the global function.
> we need "namespace
> autoloading", which in practice means autoloading any of the items you can
> put in a namespace.
Good point.
So maybe what I'm really proposing is just simply a change to
functionality - so that function and constant references do not
trigger auto-loaders, but instead the "use const" and "use function"
statements do.
I guess this deviates from the way auto-loading works for classes, too
- just in a different way... so maybe it's not much better.
Come to think of it, maybe it's worse, because this would aggressively
trigger auto-loading for functions that might never get called, so,
hmm...
I think, in practice, it's not going to work much differently from the
other proposed work-around though - if only qualified references
trigger auto-loading, then this would trigger auto-loading:
\foo\bar();
And this would too:
use foo\bar;
bar();
But this would not:
bar();
And that could get pretty confusing, since the unqualified call site
looks identical to the qualified call site.
Ugh.
Well, I guess this is what lead to a discussion about a breaking
change to the name resolution rules?
Is there an RFC detailing that idea? Or what was the title of that
discussion? I'd like to read up.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
