> 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?
Assuming you mean "unless they don't" is the additional inconsistency:
I still see this as a cleaner/less verbose option than the currently available
options
for avoiding ambiguity - aliases add similar resolution behavior.
"function_name() will search the current namespace first,
then the global namespace,
unless "use function [.... as] function_name" was found
earlier in the namespace block."
> 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.
That was unintuitive to me -- but it is one-time.
(ignoring optimizations of specialized opcodes
and inlining results as constants)
Running the following example outputs "Length is 4" twice.
<?php
namespace NSTest;
function computeStrlen() {
printf("Length is %s\n", strlen("test"));
}
computeStrlen();
require 'b.php';
computeStrlen();
// contents of b.php
<?php
namespace NSTest;
function strlen($x) {
return -1;
}
> In future, I think the optimal solution is opt-in deprecating fallback
> to the root namespace using a declare.
> ... Id like to see nikic/scalar_objects added to the core in 8.0
Various global functions (strlen(), count(), class_exists(), is_string(), etc.)
are more frequently used than namespaced functions in many files,
and removing the fallback *to* the global scope would break most third party
code,
which might be unmaintained.
This backwards compatibility break would discourage upgrading
to future major versions.
> 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.
Out of scope of this RFC: I had a thought today about autoloading.
I'd rather improve function / const autoloading instead of moving to classes.
What if an ambiguous function_name() or const outside the global
namespace would attempt to autoload *ambiguous* functions in the global scope,
but not the current namespace?
(and autoload unambiguous functions in their respective scope)
function_exists() or defined() would not autoload,
to preserve the behavior/performance of current programs.
Anything with the callable type hint (e.g. array_map) would also need to be
modified.
- Same for global constants
- That should avoid the performance hit - this autoloading would only be
triggered
when php would previously throw an Error or warning
for undefined functions/constants.
- This would also avoid the need to load polyfill files (e.g. mbstring)
or test framework files when their functions/constants are unused.
- The main blocker for other autoload proposals
seemed to be performance if I understood correctly
(e.g. attempting to autoload NS\strlen() every time strlen was called)
Fully-qualified calls (through use, \, or being in the global scope) would
autoload the unambiguous name for missing functions.
And there'd have to be a hash map or other check
to avoid recursion on the same constant/function.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
