Hi internals,
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
> Saving two characters per file doesn't seem like a great motivation to add
> additional special cases to core language syntax.
> Right now, declare just types "identifier = expr", while with this change
> it's going to be "identifier = (expr | a | few | extra | keywords)".
Thinking about it again, I'd agree with the parsing special cases being
inconvenient.
> So, most references are to classes outside the current namespace. The number
> of references to global classes and classes in the same namespace is actually
> pretty similar, there are 5% more global references.
> From that perspective, changing the name resolution rules to always look for
> the global symbol if unimported would actually slightly reduce the number of
> necessary "use" statements.
It would be more understandable for new php developers familiar with other
languages if name lookup was consistent across classes.
I don't have as strong a use case for this as I do for eliminating the
function/const ambiguity. Changing class resolution (via automated tool) would
require more code changes than function/constant resolution, and the classes
are already unambiguous.
> If we were to make such a change (hypothetically), the way I would view it is
> "use new name resolution rules" or not, rather than a collection of
> fine-grained options.
> Notably Rust made a major change to how symbols are
> resolved in the 2018 edition, so
> such things aren't inconceivable, especially with the right tooling.
If a setting affecting all name resolution was added, then forbidding the use
of both that new setting (e.g. <name_lookup=global>) and
declare(function_and_const_lookup) in the same file would keep code simpler.
If "use new name resolution rules" was the only option, the larger amount of
refactoring for class references (and doc comments) might discourage using the
new name resolution for functions/constants, and make backporting patches to
previous major versions of applications/libraries more error prone (e.g.
\MyNS\Exception vs \Exception). The refactoring might also be perceived as
risky.
So I'd still want to see the voting results&feedback for
function_and_const_lookup before investigating approaches to changing class
resolution.
Rust would also catch many more possible bugs in symbol resolution at compile
time.
The static analyzers for PHP can detect almost as many bugs, but would require
that people be aware of the analyzers, configure them, and use them in CI.
- Code such as if (class_exists(SomeClass::class)) { /* Use SomeClass */ }
might be permitted if analyzing class_exists conditionals is a feature of a
static analyzer.
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
