[VOTE] declare(function_and_const_lookup='global')

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

On Tue, Jan 28, 2020 at 9:22 PM tyson andre <tysonandre775@hotmail.com> wrote:

Notwithstanding the excellent work done in the PR, I lean toward a No vote. Suppose I'm presented with this diff (and only this diff): $a = array_diff($x, $y); + if (count($a)) die('Unexpected differences'); Where does count come from? I can't tell from this diff. It could be local to this namespace, or it could be global. In the current implementation, I have to scroll to the top of the file, check for what namespace I am in, and what use are made. In the proposed implementation, I have also to check the top of the file, but now its for "declare(function_and_cost_lookup='global')" and the presence (or not) of "use function count". It's not clear to me this is an improvement over status quo. Indeed, I worry that implementing the proposal may increase overall cognitive burden for PHP developers. Today, any developer can look at any file or snippet in any code base, anywhere in the world, and know that using an unqualified name follows a single, language-defined algorithm. Were this proposal accepted, developers no longer have that guarantee. The code might be using the original algorithm, or it might be using the new algorithm. The only way to know is to check for and remember the state based on the presence of -- and value of -- this new declaration. Resolving ambiguities has a compute cost and a cognitive cost. While the proposal improves the compute cost, I'm not sure the same can be said of the cognitive cost. So I am leaning toward a No vote. What do you think?

Hey Tyson, I voted "No" on this one, sorry. TL;DR: I'd rather have a mechanism to disable global function fallback, not something that makes un-imported symbols immediately global. The idea to disable PHP's implicit "fallback-to-something-that-may-or-may-not-exist" is great, and it could simplify some of the engine, as well as remove some caching mechanisms (lookup) in some contexts, but I'm pretty happy with disabling all global lookup functionality, rather than making them the default. I don't have a problem with `use function sprintf;` to import things from PHP, and actually use it to quickly grep whenever I do something extremely dangerous (like `use function umask;`). This gives me also a good overview of how much of the global symbols are still in my system, and to be replaced with something like `thecodingmachine/safe`. I also deal with merge conflicts regularly: not a big issue either. Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On Wed, Jan 29, 2020 at 3:22 AM tyson andre <tysonandre775@hotmail.com> wrote: