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

Reply via email to