On 01/01/2020 19:31, tyson andre wrote:
This RFC proposes to support an opt-in "use global functions/consts;" statement
to disable PHP's check for the function/const in the current namespace before falling
back to the global namespace.
It's an interesting idea, but at this time I think it's the wrong
approach to what is in the best long-term interests of the language by
introducing an additional point of inconsistency.
Classes search the current namespace, but functions / const would search
namespace first, unless they don't, then global?
For the very minor one-time performance hit (thanks to the cache slot),
I think the situation is best remaining as-is for the time being.
In future, I think the optimal solution is opt-in deprecating fallback
to the root namespace using a declare. We might eventually benefit from
versioned "libraries" of functions that can be imported in one command
which would solve many-a-future-problem by itself.
Somewhat related is how global functions are consumed -
Id like to see nikic/scalar_objects added to the core in 8.0, that would
offer non-procedural (and therefore non-namespaced) access to many of
the most common global functions (strings, arrays etc). In turn, that
would allow developers to limit the number of use \... statements.
That doesn't cover defined constants, but IMO we should be pushing those
to be moved into class constants, simply because in the absense of
function / constant / anything-but-class level autoloading, things might
as well be in a readily available location.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
