Note that I say "try internal" because the only purpose behind allowing
this is to make it easier to use PHP's built-in functionality. Any
userspace stuff should be specifically \prefixed or imported via use.
And (yes) we need import for functions.
Greg
P.S. my mail server has been down for almost a week, apologies to anyone
who is wondering why I haven't replied to your message, I probably
didn't get it.
Hi,
This is starting to bother me, to be honest. Every time we go back to this
"fallback to internal X" I give examples and real world scenarios that will
become broken in namespaces which work today outside a namespace.
I get nods, agreement, people start talking that we should either fallback
to *all global* functions, or *not fallback at all* so that the behavior is
predictable for PHP users.
... And in few days we all forget problem and start talking about falling
back to *internal* again.
People do implement fallbacks for internal functionality as userspace
functions/classes on their own, TODAY. In namespace, if you don't treat
internal/user equally in resolution, things will work outside a namespace,
and break inside it. This will be confusing to people, who especially use
fallbacks to transparently implement missing PECL extensions or
functionality, or augment the internal functions of PHP with other, for ex.
user implemented ifsetor(), array_*() or str*() functions.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
