Re: Re: [RFC] "use global functions/consts" statement

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