Re: [VOTE] declare(function_and_const_lookup='global')

This is only part of a thread. view whole thread
  108307
January 29, 2020 04:03 theodorejb@outlook.com (Theodore Brown)
On Tue, Jan 28, 2020 at 8:22 PM tyson andre <tysonandre775@hotmail.com> wrote:

> Hi internals, > > I've opened the vote on https://wiki.php.net/rfc/use_global_elements
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. 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)? 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. Best regards, Theodore
  108308
January 29, 2020 04:48 larry@garfieldtech.com ("Larry Garfield")
On Tue, Jan 28, 2020, at 10:03 PM, Theodore Brown wrote:

> 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.
Without weighing in on the RFC itself, I really don't think this statement is true anymore. Back in the day, sure; autoloading for class-like-things only made functions second class citizens. However, Composer use is now near-universal for new code. Composer can load specific files full of functions during autoload just fine, and then the functions are universally available. That would have been a performance hit, but with opcode caching the hit is minimal. With preloading in 7.4, even that is reduced to almost zero. Between those two, having a library that is mostly a pile of namespaced functions that are just always-available is quite reasonable and feasible these days. Whether it's architecturally good or bad is another question, but I don't think the lack of autoloading is a good excuse anymore. --Larry Garfield
  108309
January 29, 2020 06:18 tysonandre775@hotmail.com (tyson andre)
> 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.
  108314
January 29, 2020 10:06 marandall@php.net (Mark Randall)
> On Tue, Jan 28, 2020 at 8:22 PM tyson andre <tysonandre775@hotmail.com> wrote: >> I've opened the vote on https://wiki.php.net/rfc/use_global_elements
I too would like to thank you for the effort put in, but I find myself in agreement with several of the other posters that I'm not sure this is the right way to go about it. I'm not a fan of the disparity between classes and functions that this would introduce if used. Support for namespaced level functions is already quite poor (with lack of autoloading) and rather than try to gain a few bytes here and there, I think the better long-term option would be to simply remove support for them entirely in favour of static methods, and at that point the door is open to make functions and constants be global-only. -- Mark Randall