[RFC] "use global functions/consts" statement View as Markdown

Hi,

I object to the following proposed behaviour, which is confusing:

<?php
declare(function_and_const_lookup='global');

namespace MyNS;

function sprintf($msg, ...$args) {
// this and remaining statements still refer to \sprintf, not MyNS\sprintf
return sprintf("Prefix $msg", ...$args);
}
?>

I think we can do better, following the example of what we have today, namely: Currently, the following triggers a fatal error:

<?php
namespace MyNS;
use function OtherNS\foo;

function foo() { }
// Fatal Error: Cannot declare function MyNS\foo because the name is already in use
?>

Therefore I suggest that the following be an error:

<?php
declare(function_and_const_lookup='global');
namespace MyNS;

function foo() { }
// Fatal Error: Cannot declare function foo because the name refers is in the global namespace

?>

and that you have to explicitly say that you use the current namespace for that name:

<?php
declare(function_and_const_lookup='global');
namespace MyNS;
use function MyNS\foo;
// or, equivalently: use function namespace\foo:

function foo() { }

foo(); // <-- this is the function defined just above

?>

—Claude

https://wiki.php.net/rfc/use_global_elements and the implementation
has been updated again - the syntax is now declare(function_and_const_lookup='global')
with a literal string instead of a keyword.

The voting option for whether it was a string or a keyword was removed.
I plan to move this to the voting phase on Monday, if nothing else
needs to be addressed

I have a few questions and concerns:

1. Is it a typo that the first code example in the proposal has a
   namespace declaration before the declare statement? Currently it is
   a fatal error if a strict_types declaration isn't the first
   statement in a file. Are you intending to change this restriction,
   or have it not apply to the function_and_const_lookup declaration?

2. How will this RFC fit into "future work on autoloading" (mentioned
   as a benefit in the discussion section)? Would autoloading only be
   possible for files with declare(function_and_const_lookup='global');?

This RFC seems like a pragmatic attempt to solve the global/namespaced
ambiguity issue for the way code is typically written today (most
const/function uses in a namespace being global yet unqualified).
However, isn't the current lack of autoloading part of the reason for
this usage pattern? Personally I would love to write more plain
functions in namespaces, but am forced to use static class methods
instead to benefit from autoloading.

In other words, if PHP had function autoloading, there would be more
usage of namespaced functions, in which case changing function and
const lookup to global becomes less helpful. In this way the RFC seems
to work against one of its own goals.

I would find it quite annoying and counterintuitive to have to
explicitly use namespaced functions and consts in the same file
they are defined in. The example in the RFC of a function defined in
a namespace that appears to call itself but actually calls a different
global function is particularly confusing.

I'd really like to see a more complete proposal that thinks through
how it will fit in with future autoloading and the way people will
then write code, rather than just the way they write it today due to
current limitations.

Long term I think it would be better to have a declare(global_lookup=0)
option which could be applied to a set of namespaces, and a registered
function/const autoloader would only be triggered for those namespaces.
This would allow function autoloading to be used without hurting performance or breaking existing libraries.

Le 28 janv. 2020 à 10:50, Nicolas Grekas nicolas.grekas+php@gmail.com a écrit :

BTW, should we use the word "root" instead of "global"? "global" might have
a bad connotation, and "root" is the word used in the description of the
current behavior of PHP:

“Global” is the term used in the manual: https://www.php.net/manual/en/language.namespaces.php https://www.php.net/manual/en/language.namespaces.php

—Claude

Thanks. It's a bit strange to read the objections to the proposal in the RFC.
That makes it feel like "we" agreed on them - while it's "only" the author's opinion. From this part in the RFC:

It's included because https://wiki.php.net/rfc/howto mentions the following:

"Listen to the feedback, and try to answer/resolve all questions.
Update your RFC to document all the issues and discussions.
Cover both the positive and negative arguments. Put the RFC URL into all your replies."

This is why I included major points from the arguments for/against
in https://wiki.php.net/rfc/use_global_elements

and changing that default would require changing a lot of third party code.

not unless it's opt-in, which it is.

Good point, I've changed this to be clearer about what I meant and add missing details..

It's fairly common for NS\SubNS\ClassName to mention other classes from NS\SubNS\OtherClassName right now,
(more commonly than use Exception, use Throwable, etc in some cases),
and [opting into that a single setting such as declare(global_lookup=1)]
would require changing a lot of third party code [to get unambiguous function and constant resolution easily].
A separate option such as declare(lookup_classes=global) would allow migrating to that,
but would confuse developers switching between codebases using different settings of lookup_classes,
and introduce similar confusion about the rare case of multiple classes in one file.

A separate option such as declare(lookup_classes=global) would allow migrating to that,

better have lesser declare() directives IMHO.

It's impossible to agree on everything. I don't believe anyone's actively working on lookup_classes or global_lookup right now,
so there might still be only one declare directive for name lookup a long time from now.

but would confuse developers switching between codebases using different settings of lookup_classes,
and introduce similar confusion about the rare case of multiple classes in one file.

Not sure how this would be different than any other declare directive - either the currently proposed one or even strict_mode.

https://wiki.php.net/rfc/use_global_elements is opt-in, and also doesn't need to deprecate anything. The link you mention
is a different proposal that has deprecations for constants and functions.

I'm not comfortable with having a 3-ways declare directive. Who will pick which of the 3 and for what reason?
That's going to be a mess to review. If we're looking for a forward path, there should be only one opt-in way: a boolean flag.

I'm not sure what you mean by 3 ways. It's at most two, and a setting for global name lookup might become mutually exclusive (forbid using both setting names)

I meant 'default', 'fallback', 'global', and declare()-omitted. Rowan's latest message is a better ground to discuss this so let's continue there - I share his concerns.

For the reasons I mentioned earlier, I don't want to add a 'fallback' setting 2 ways either,
because it'd potentially constrain other RFCs unrelated to this one in ways I can't anticipate.
(e.g. will they emit a deprecation notice for 'fallback' and suggest using 'fallback_v2' or a new 'default'?)

You mention this should be another RFC. But process-wise, I think it would be better to vote only once on a specific topic, vs having several iterations that undo previous RFCs before having a stable consensus.

The issue with that is that there's no good way to set up a vote or poll for that in the RFC structure.

For sure, I'm not suggesting to add a sub-vote. I think we should be able to discuss the best proposal we can imagine all together and put it under a yes/no vote.

• There were a lot of edge cases to work out for functions and constants, and many approaches to dealing with that.

  There would similarly be edge cases for classes, and the same approach of adding use MyNS\MyName;
  before the class declaration class MyName would have other objections,
  and would probably also affect the resolution of
  namespaces (MyName\MySubNS\MyActualClass and MyName\my_function()

• Implementing and discussing changes to class resolution to see if they would be viable or has unexpected edge cases (while creating a proposal before voting on it) is time intensive.

  If I expect a vote on additionally changing class resolution to fail due to the edge cases and drawbacks I mentioned
  or objections to the final proposal, there's less incentive to personally do that work,
  and I'm not aware of other developers working on a detailed proposal for changing class resolution.

  The alternative of not creating an implementation it and not creating a draft RFC before voting would lead people to vote on something with an incomplete understanding
  of the impacts and viability of changing class (and possibly namespace) resolution.

Of course, I could be completely misjudging interest,
and an RFC for opt-in changes to class resolution may pass and solve these issues in ways I couldn't think of right now.

I'd see global_lookup=1 and function_and_const_lookup='global' as being significantly different in who would vote on them.
The former requires a lot more refactoring and code changes to handle changes to class name resolution,
compared to the code changes of just changing function and constant resolution.

No proposal requires any refactoring if things are opt-in: existing codebases will continue to work as-is.
New ones might start with the new declare directive. Existing codebases could also adopt the directive once the tooling is ready. Eg. php-cs-fixer has all the required infrastructure to automate this transition for authors that want to do it.

And because changing resolution of class names has those drawbacks, I don't plan to change direction within this RFC.

I don't see these as drawbacks, especially when the target is cleaning up the rules of the engine for a better future :)

Can you please consider it? While this reply might feel like I'm "just" criticizing your work, it's not: I'm very thankful for what you're doing here and I think you are doing a great job.
I'm "just" trying to help shape the best proposal for the best future of PHP, although very modestly :)

I am thankful for all of the feedback on the RFC.
I have considered the feedback and responded to it,
but I just see too many potential problems with changing class resolution
to be included in the scope of this RFC.