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

> > One option that I haven't seem much discussion on is the opposite: Always > only look in the global namespace. Any unimported unqualified usages will > > be treated as fully qualified names. This would match the proposed > > semantics for functions/consts and change the resolution rules for classes. > > > > I think this would have relatively little impact on how code is written, as > > classes already tend to make extensive use of cross-namespace references > > and the import is usually IDE managed. > > Quick reaction: that'd make sense to me! > > Adding a "use CurrentNamespace\Foo" or using "namespace\Foo" looks easy > enough to adopt. > Does this mean you're suggesting to use > declare(symbol_lookup='global')? Or shorter: declare(lookup='global'), or > maybe even declare(global_lookup=1) as I'm not sure we need 3 options here? The RFC has been updated after feedback, but I forgot to update the wiki and PR title. I sent out an email last week mentioning that https://wiki.php.net/rfc/use_global_elements is now a single declare() setting declare(function_and_const_lookup=global) > Always only look in the global namespace. Other RFCs have proposed that approach. I mentioned the objections others had to that RFC in https://wiki.php.net/rfc/use_global_elements#deprecate_the_fallback_to_the_root_namespace_instead "Deprecating the behavior of existing code would break (possibly unmaintained) third-party libraries and require a lot of code changes, discouraging updates to the latest version of PHP." > I like the idea of using a meaningful value here, but think that this > should be using a string, i.e. declare(function_and_const_lookup='global') > rather than declare(function_and_const_lookup=global). Currently declare() > syntax uses a normal constant expression on the right hand side of the =, > and I don't see a strong reason why we should deviate from that for this > feature. An existing declare using a string is declare(encoding='UTF-8'). Whether it's quoted is a low priority to me - I went with the unquoted implementation because it might be something repeated in every file of a project, and it'd be slightly more convenient to avoid quotes and use keywords if there were many more settings with different values (=on, =off, =warning, etc) in the future. A difference is that it makes sense to quote encodings such as UTF-8 because of the '-', but not as much to quote keywords without special characters. > It looks like the implementation has been updated to the style proposed > here, while the RFC still uses disable_ambiguous_element_lookup. Fixed, forgot to update the wiki after updating the implementation