> can we please discuss this alternative? In another reply, you link to > https://wiki.php.net/rfc/use_global_elements#deprecate_the_fallback_to_the_root_namespace_instead > > But this new proposal derived from Nikita's idea is different as it doesn't > need to deprecate anything.
I've added https://wiki.php.net/rfc/use_global_elements#add_setting_to_make_all_name_lookups_global_instead_eg_declare_global_lookup_1 to the discussion notes for the RFC. https://wiki.php.net/rfc/use_global_elements is opt-in, and also doesn't need to deprecate anything. The link you mention is a different proposal that has deprecations for constants and functions. > I'm not comfortable with having a 3-ways declare directive. Who will pick > which of the 3 and for what reason? > That's going to be a mess to review. If we're looking for a forward path, > there should be only one opt-in way: a boolean flag. I'm not sure what you mean by 3 ways. It's at most two, and a setting for global name lookup might become mutually exclusive (forbid using both setting names) https://wiki.php.net/rfc/use_global_elements is 1 way right now. `declare(function_and_const_lookup='global')` If anyone made a proposal for class names in the future, it would probably be 2 way. > 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. As it understand it, "use new name resolution rules" (a single RFC for everything, including class names) is a discussion on how name resolutions could be changed to measure interest and get arguments for/against, and not something being advanced as an RFC right now. > I think that's all we need to make all symbols resolve in the same way, known > at compile time. > > You mention this should be another RFC. But process-wise, I think it would be > better to vote only once on a specific topic, vs having several iterations > that undo previous RFCs before having a stable consensus. The issue with that is that there's no good way to set up a vote or poll for that in the RFC structure. I'd see global_lookup=1 and function_and_const_lookup='global' as being significantly different in who would vote on them. The former requires a lot more refactoring and code changes to handle changes to class name resolution, compared to the code changes of just changing function and constant resolution. The reason I'm not trying to make a secondary vote on this is similar to the reasons why "use function..." vs "declare()" was a bad idea to vote on in a previous version of my RFC. And because changing resolution of class names has those drawbacks, I don't plan to change direction within this RFC. > I don't think it's a good idea to resolve the question of "use global > functions" vs "declare" as a subsidiary vote. At least in my mind, those > two options are significantly different, and this choice would affect both > my overall opinion of the proposal and also the answer I would give on some > of the other voted question. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
