> 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:
It's included because https://wiki.php.net/rfc/howto mentions the following: "Listen to the feedback, and try to answer/resolve all questions. Update your RFC to document all the issues and discussions. *Cover both the positive and negative arguments.* Put the RFC URL into all your replies." This is why I included major points from the arguments for/against in https://wiki.php.net/rfc/use_global_elements > > and changing that default would require changing a lot of third party code. > > not unless it's opt-in, which it is. Good point, I've changed this to be clearer about what I meant and add missing details.. > It's fairly common for NS\SubNS\ClassName to mention other classes from > NS\SubNS\OtherClassName right now, > (more commonly than use Exception, use Throwable, etc in some cases), > and [opting into that a single setting such as declare(global_lookup=1)] > would require changing a lot of third party code [to get unambiguous function > and constant resolution easily]. > A separate option such as `declare(lookup_classes=global)` would allow > migrating to that, > 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. > > A separate option such as `declare(lookup_classes=global)` would allow > > migrating to that, > > better have lesser declare() directives IMHO. It's impossible to agree on everything. I don't believe anyone's actively working on `lookup_classes` or `global_lookup` right now, so there might still be only one declare directive for name lookup a long time from now. > 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. For the reasons I mentioned earlier, I don't want to add a 'fallback' setting 2 ways either, because it'd potentially constrain other RFCs unrelated to this one in ways I can't anticipate. (e.g. will they emit a deprecation notice for 'fallback' and suggest using 'fallback_v2' or a new 'default'?) > > 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. - There were a lot of edge cases to work out for functions and constants, and many approaches to dealing with that. There would similarly be edge cases for classes, and the same approach of adding `use MyNS\MyName;` before the class declaration `class MyName` would have other objections, and would probably also affect the resolution of namespaces (`MyName\MySubNS\MyActualClass` and `MyName\my_function()` - Implementing and discussing changes to class resolution to see if they would be viable or has unexpected edge cases (while creating a proposal before voting on it) is time intensive. If I expect a vote on additionally changing class resolution to fail due to the edge cases and drawbacks I mentioned or objections to the final proposal, there's less incentive to personally do that work, and I'm not aware of other developers working on a detailed proposal for changing class resolution. The alternative of not creating an implementation it and not creating a draft RFC before voting would lead people to vote on something with an incomplete understanding of the impacts and viability of changing class (and possibly namespace) resolution. Of course, I could be completely misjudging interest, and an RFC for opt-in changes to class resolution may pass and solve these issues in ways I couldn't think of right now. > > 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 :) I am thankful for all of the feedback on the RFC. I have considered the feedback and responded to it, but I just see too many potential problems with changing class resolution to be included in the scope of this RFC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
