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

Le lun. 27 janv. 2020 à 16:10, tyson andre <tysonandre775@hotmail.com> a écrit : > > 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. > Thanks. It's a bit strange to read the objections to the proposal in the RFC. That makes it feel like "we" agreed on them - while it's "only" the author's opinion. From this part in the RFC: > and changing that default would require changing a lot of third party code. not unless it's opt-in, which it is. > A separate option such as declare(lookup_classes=global) would > allow migrating to that, better have lesser declare() directives IMHO. > but would confuse developers switching between codebases using different settings of lookup_classes, > and introduce similar confusion about the rare case of multiple classes in one file. Not sure how this would be different than any other declare directive - either the currently proposed one or even strict_mode. 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) > I meant 'default', 'fallback', 'global', and declare()-omitted. Rowan's latest message is a better ground to discuss this so let's continue there - I share his concerns. BTW, should we use the word "root" instead of "global"? "global" might have a bad connotation, and "root" is the word used in the description of the current behavior of PHP: declare(function_and_const_lookup='root') > 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. > For sure, I'm not suggesting to add a sub-vote. I think we should be able to discuss the best proposal we can imagine all together and put it under a yes/no vote. Reusing the "root" word, I think we might want to upgrade the current proposal to: declare(root_lookup=1) 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. > No proposal requires any refactoring if things are opt-in: existing codebases will continue to work as-is. New ones might start with the new declare directive. Existing codebases could also adopt the directive once the tooling is ready. Eg. php-cs-fixer has all the required infrastructure to automate this transition *for authors that want to do it*. > And because changing resolution of class names has those drawbacks, I > don't plan to change direction within this RFC. > I don't see these as drawbacks, especially when the target is cleaning up the rules of the engine for a better future :) Can you please consider it? While this reply might feel like I'm "just" criticizing your work, it's not: I'm very thankful for what you're doing here and I think you are doing a great job. I'm "just" trying to help shape the best proposal for the best future of PHP, although very modestly :) Doesn't anyone else share my points? Nicolas