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

On Sun, Jan 26, 2020 at 10:25 AM tyson andre <tysonandre775@hotmail.com> wrote: > 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.