> Thank you for working to address the issue of ambiguous function references. > However, I really don't think this is the right approach. > > The RFC mentions two problems it hopes to solve: a minor performance > decrease, and developers having to deal with ambiguity. > However, a third problem that I think is just as important to fix is the lack > of function autoloading which makes extensive use of namespaced functions > unfeasible. > > Unfortunately, the new directive proposed by this RFC would make declaring > functions in namespaces even more difficult, as it would now be necessary to > explicitly `use` each function and constant in the same file it is declared > in.
I'd expect that autoloading of those declared functions would work whether or not the functions were *declared* in a file with or without `declare(function_and_const_lookup='global')`. It'd be the *uses* of the functions that would be problems, if function autoloading was implemented but limited to uses of names that could be resolved without fallbacks. As I see it, - Many forms of function autoloading would be argued against if most PHP code would end up ambiguously referencing functions, because you either sacrifice performance or correctness to deal with the ambiguity. (right now, php permanently caches the resolved ambiguous function the first time it is called) - If unambiguously referencing functions was made less difficult, then there would be more support for implementing function or constant autoloading. > The RFC argues that having to "add multiple `use function function_name` and > `use const MY_CONST` at the top of the namespace" is prone to merge conflicts > and inconvenient to keep up to date. However, the RFC just shifts this > problem from global functions to namespaced functions. > > Changing function/const resolution to always look in the global scope instead > of current namespace is backwards from how classes and interfaces are > resolved, and seems destined to become another language Sadness. > Wouldn't it be more straightforward and intuitive to add a directive like > `declare(namespace_lookup=1)` which would resolve functions/consts the same > way as classes (without the global fallback)? https://wiki.php.net/rfc/use_global_elements#look_up_elements_in_the_current_namespace_instead_of_the_global_namespace was brought up earlier. Right now, the majority of PHP's functions are in the global namespace. (count(), strlen(), is_string(), etc.) I agree it'd be more straightforward, but I don't have a personal reason to propose or use a change that would make core functionality such as `is_string` harder to use. If php's core functions and constants weren't almost all in the global namespace, then I'd have more reasons to propose `declare(namespace_lookup=1)` instead of this. > The RFC argues that writing global functions as `\function_name()` is more > verbose. > But is one backslash character per global function call any more verbose than > having to add a 44-character declare statement at the top of every file? > Developers are already used to referencing global classes and functions with > backslashes or explicit `use` statements, > and in a future where we have function autoloading and utilize more > namespaced functions, > this approach will be less verbose than having to explicitly `use` every > namespaced function in the same file it is declared in. > Plus, IDEs and other tools can automatically add the backslashes or `use` > statements for global functions. To expand on why I'm suggesting this as an alternative to `\function_name()` in https://wiki.php.net/rfc/use_global_elements#introduction, - A developer context switching between code bases that require/prefer `function_name()` and another requiring `\function_name()` would not get used to it. If function_and_const_lookup='global' was added, they would not need to context switch, and would just write `function_name()` in both projects. Having the equivalent of a `.phpeditorconfig` could avoid the need for thinking about it, but getting that supported in all common IDEs would have roadblocks (e.g. hypothetical plugins may require the user must configure the path to php 7.4 for their .phpeditorconfig to work, and there's no such thing of .phpeditorconfig for php syntax to my knowledge) - I'd prefer the syntax for unambiguously using built-in functionality be convenient to use. - New contributors to a project wouldn't expect that builds fail (etc.) because the `is_string` wasn't quoted. Many wouldn't have their IDEs set up to do add the use statements or `\`. - For existing projects that start switching to unambiguous names, `git blame` would be less useful on the line `if (!\is_string()) { ... }` because the most recent commit could be one one adding the `\`. - This provides another option for developers that did want less ambiguity but didn't want to use either `use function function_name;` or `\function_name()` for the reasons mentioned. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
