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