Re: [RFC] "use global functions/consts" statement
| From: | tyson andre | Date: | Mon, 27 Jan 2020 14:43:21 +0000 |
| Subject: | Re: [RFC] "use global functions/consts" statement | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-108268@lists.php.net to get a copy of this message | ||
> This would be a compile error right now though, because we don't allow "use"d
> symbols and declarations to clash.
As I surprisingly discovered when implementing the RFC, they don't clash.
The PHP interpreter has a special case where it doesn't warn or throw about the name being in
use
if the resolved (namespaced) name in use is the same as the element being declared.
See https://3v4l.org/RtPKv - the below example works.
```
<?php
namespace NS;
use function NS\foo;
use const NS\BAR;
function foo() { echo BAR; }
const BAR = 3;
foo();
```
> While I was the one who originally suggested to allow this kind of code,
> I think it might be better to just unconditionally make it a compile error,
> and require the use of declare(function_and_const_lookup='default')
> if you want to declare namespaced constants or functions.
>The main motivation for allowing it is interoperability with namespace-scoped declares,
> but as those don't exist yet (and would still allow a per-file opt-out), we can delay this
> issue.
>
> I think that principally, the correct behavior here is to bring the symbol into scope as it is
> declared,
> but as you already pointed out, this leads to unclear semantics when conditional function
> declarations are involved.
The subset of code that can be written requiring "use function NS\foo;" and "use
function NS\MY_CONST;"
with function_and_const_lookup='default' is larger than forbidding it completely, while
still avoiding ambiguity.
> As a minor note, rather than using 'default' as one of the values,
> I think it would be better to use 'fallback' to make it robust against a potential
> future change of defaults.
I'd rather have that done when the future change of defaults is being proposed.
Supporting 'fallback' might cause confusion and extra work if the name resolution defaults
ever change in a different way.
At the point where they do change, we either do or don't want a way to support the old
'fallback',
but we will want to support the new 'default'.
Right now, it's deliberately intended to be the same as just leaving the setting off for that
file.