Here is a reason why we would limit this to international functions only:
- <@Stas> but note that global user-space fallback for function means
run-time resolution (which may be ok, but slower - no caching resolution
in bytecode cache)
Hi,
Not true: you can't resolve it at compile time with internal-only functions,
since you still don't know what *namespaced user functions* will be loaded
at runtime with overlapping names.
I.e. :
----FILE aaa.php----
namespace Foo;
function strpos() {}
----FILE bbb.php----
namespace Foo;
if (runtime condition) include 'aaa.php';
strpos(); // parse-time resolution will ignore the loaded Foo\strpos() and
resolve to internal anyway.
So, no performance benefit whatsoever, any fallback requires *runtime*
resolution.
Furthermore, don't you guys see that coding IDE-s will have issues with code
hinting those functions. Is it the namespaced function or the global one?
The IDE can't know, an IDE can't resolve vague runtime conditional includes.
Eclipse PDT works great right now, with autoload and all, since it a given
functionc/class identifier can be either internal, or in the project, and
each has a unique name. With the magical fallbacks, all this goes to hell.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
