Re: Autoloading functions/consts without a performance impact

> Yes, I'm saying that the autoloader should be called for each lookup, so > autoloading of Foo\strlen should come between checking if Foo\strlen is > defined, and checking if \strlen is defined. That would be the intuitive approach for a language, but as mentioned earlier, it would significantly harm performance of existing code for php 7 (slightly without an autoloader, more with autoloaders), and I can't imagine that getting approved. - One option I'd thought of is to invalidate runtime caches of ambiguous calls' opcodes when the set of autoloaders change. This is technically possible, but it would make spl_autoload_register()/spl_autoload_unregister() extremely slow for large applications. (it would be implemented by iterating over all functions/closures/methods/global scopes and deleting the runtime cache entry for those call opcodes.) That way, if a new autoloader got registered, existing unqualified calls to strlen() would check for \Foo\strlen once, the next time they were called. I don't have any plans to try this or work on this approach, but it's worth noting that it's possible. This approach is taken in http://github.com/runkit7/runkit7 when modifying definitions of internal functions (runkit_function_redefine()), etc. > Then maybe we should target the feature at those use cases - don't call the > autoloader *at all* unless we know the fully-qualified name, and give up > trying to "square the circle" by combining fallbacks with autoloading for > unqualified names? The largest issue with that is that unqualified names are extremely common in php 7 code. I'd considered that option, but that introduces its own surprises, which I'd consider to have more frequent and significant impact on applications that start using this. namespace NS; function f1($x) { return mb_strlen($x) + 1; } function f2($x) { return \mb_strlen($x) * 2; } Calling f2() then f1() would work, but f1() then f2() would not work, because f1() wouldn't autoload. - ASIDE: I guess something along these lines would be less likely to *cause surprises* if one implemented "autoload, but only for qualified functions outside of the global namespace, but autoloading global functions is my main reason to want this with current code (e.g. polyfills).