Hi Jordan, On Tue, Aug 24, 2021 at 4:55 PM Jordan LeDoux <jordan.led...@gmail.com> wrote:
> 1. Are too large or complex for voters to make an informed decision about. This is the real problem. Also you are correct on the cause (complexity of a topic), I don't think we are not able to understand complex RFCs. > 2. Include too many aspects which are controversial or which have strongly > opposed viewpoints within the RFC voters. Incomplete implementation of a language construct is an order of magnitude worse than having to wait a bit longer. > RFCs which do either of these two things cannot pass, therefore all RFCs > which pass do neither. Together with others I wrote the RFC RFC along with a few required after this. I fully grasp how hard it can be at times. However language constructs are not some random extensions we can drop, replace etc. They are basically there forever. And forever in my case is as long as PHP exists. What is one more year then? :) > and new language features. Which should be clearly complete to begin with, as much as possible. A hard to find agreement is not a good enough reason to push a new incomplete language feature, in my book. This is my only point. > These are not bad things to value, and I don't see how you can expect RFC > authors to avoid proposing features which some may see as incomplete. My > operator overload RFC is something I've already put at least 100 hours into, > it's trimmed down to a very limited set of operators with restrictions on > certain implementations, I still have many more hours of work left on the > implementation in order to make the necessary changes to opcodes for it, and > it still will likely be something which there is significant resistance to. I > might put in excess of 300-400 hours of work into this RFC only for it to be > rejected because of differences of opinion on the feature. You most likely will, and we are all grateful for that. It also shows that such RFCs are not about a single individual. Language features are better designed, proposed or implemented by a group of persons. That's the tricky part but it may help a lot. > > I would be very disappointed if I was able to successfully convince voters of > the value of my contribution, address the concerns that were presented and > find good compromises, and then be told that my work was faulty and > incomplete because it only allows operator overload for objects instead of > globally or doesn't allow overloading of the null coalesce operator, for > instance. I cannot say anything about it as I did not go through it deeply. However, yes, I would rather vote no on operator overloading not being fully documented in the RFC. I could imagine not every single case could go in the 1st round. While operators overloading add enough complexity already without having to think about where it will work and where not, as an end user. But the roadmap must then be clear, implementation etc. The idea of saying "let see later" is not a good way to accept language changes. Best, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
