> 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?
Thanks, fixed. This statement order was wrong and from a previous revision of the RFC. The restriction for `strict_types` won't change. > 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. A major objection to autoloading for functions and constants is that it's unpredictable for ambiguous elements. (so one way to implement autoloading is to *only autoload if the reference to a function or constant is unambiguous*) Right now, it's possible but inconvenient for projects to unambiguously refer to functions and constants, for the reasons mentioned in https://wiki.php.net/rfc/use_global_elements#introduction Implementing this RFC makes removing this ambiguity much easier. I wouldn't want autoloading to be limited to just files with function_and_const_lookup='global' > 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. Yes, there would be more usage of namespaced functions. However, right now, most of the references to classes are to classes in different namespaces. Most of the references to functions are in the global namespace, and of the references to functions outside of the global namespace, I'd guess that most are from a namespace *different* from the current namespace. The other goal of this RFC is to make unambiguous references convenient. "[Manually using names from the global namespace] is prone to merge conflicts when functions start/stop being used, inconvenient to keep up to date, and the vast majority of the uses will be global functions and constants." > 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. Requiring `use function MyNS\sprintf;` before the declaration of a function named `sprintf` outside of the global namespace is planned for the final version of this RFC. Same for constants. - You can use `='default'` or omit it in the files that declare functions and constants if you don't want that. That example illustrates edge cases that had to be dealt with in the RFC's implementation, and I'd expect code like that to be uncommon. Making the name resolution behavior easy to understand and not have surprising special cases was the main reasoning for implementing it this way. It shouldn't matter which function gets declared first, whether functions are reordered when refactoring, or if the body of a function gets moved to a different file. > 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. This was brought up in earlier discussion, in https://wiki.php.net/rfc/use_global_elements#deprecate_fallback_to_the_root_namespace_instead Also see https://externals.io/message/107953#107962 The "module system" idea also brought up the desire for a more complete proposal. Right now, though, a more complete proposal hasn't been created. Using `declare(global_lookup=0)` would not fix the current drawbacks of unambiguously referencing functions or constants that motivated me to create this RFC (in https://wiki.php.net/rfc/use_global_elements#introduction) Thanks, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
