[VOTE] declare(function_and_const_lookup='global') View as Markdown

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

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.

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

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.

[...]

What do you think?

Hi,

I think that when we're at a point where developers start using existing
core function names for custom functions and they start 'overriding'
things, you already have this problem, regardless of this RFC. You already
have to check whether or not the function was defined via a use statement
on top. I don't think your example of the diff would have a difference
between use and declare when it comes to reviewing.

I would advice developers to avoid using core function names in namespaces
for custom functions, as doing this would open up a whole different can of
worms when it comes to developer experience.

Regards,
Lynn

Le 29 janv. 2020 à 09:55, Bishop Bettini bishop@php.net a écrit :

Suppose I'm presented with this diff (and only this diff):

$a = array_diff($x, $y);

• if (count($a)) die('Unexpected differences');

Realistically, when I see that diff, I assume that those functions are the well-known global ones. The eventual presence declare(function_and_const_lookup='global') directive would make my assumption provable, which is an improvement. In the rare cases where that my assumption is false, an explicit use function MyNs\{array_diff, count} is welcome (and is already possible) in order to make my assumption refutable without needing to look for improbable redefinition of those functions in other files; such an explicit declaration would be mandatory in presence declare(function_and_const_lookup='global'), which is an improvement.

—Claude

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.

Agreed. I want to force explicit qualifications, and raise error on
unqualified names:

<?php
declare(strict_qualify=1);

namespace foo;

use function {array_diff, var_dump};
use const \bar{a, b};

$x = array_diff(a, b);
if (count($x)) { // throw an \Error of some kind, as count is unqualified
var_dump($x);
}

Pros... no bc break; short declare identifier with obvious values; code
valid even if declare is removed; no lookup performance penalty; easy to
remember logic; forces enumeration of the "surface area" the code wants to
cover (which in turn helps developers think about how much work the code's
doing); has analogue in other similar languages (perl, python, node); makes
explicit what functions are being used and where they originate; might goad
an implementation of wildcard use (use function {imap_*}).

Cons... have to enumerate everything, potentially lots of work to do that
to update old code to use; edge cases I'm not thinking about.

I've not done the work to implement this, though I am happy to if there's
interest. But, it may not be feasible. I'd hope Tyson would kindly say
"STFU not possible" if, from their recent experience, it couldn't be done.
Apologies if earlier thread discussion ruled this out categorically.

But I like that it adds super-strictness for those who want that, while
keeping the super-flexibility of what we have now. That seems to be the way
we're going with this dual-world of loose- and strict-ness in PHP.