On Mon, Aug 23, 2021 at 11:09 PM Pierre Joye <pierre....@gmail.com> wrote:
> > Many additions went through while being incomplete. It was documented > so in the RFC but it does not make it a good thing. Many of them are > indeed much needed and related to features (some) PHP users have been > waiting for. Are they critical enough for the PHP usage to allow them > in while knowing it is not complete? For almost all recent RFCS > related to syntax, arguments/return types or properties, I don't think > it justifies being added while being incomplete. It is not critical > enough to the larger user base. It makes migration paths harder as > well. > I just wanted to note that while this may be true, it's largely because RFC authors cannot reasonably create and pass RFCs which: 1. Are too large or complex for voters to make an informed decision about. 2. Include too many aspects which are controversial or which have strongly opposed viewpoints within the RFC voters. RFCs which do either of these two things cannot pass, therefore all RFCs which pass do neither. This will always result in RFCs which some people view as "incomplete". It's not because the RFC authors, or even the voters, forgot or "overlooked" something necessarily. It's simply a product of what the PHP voters value. Voters value backwards compatibility; voters value a strong use-case justification for a new feature; voters value consistency between existing language features and new language features. 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. 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. As long as RFC authors must lobby voters to get a feature included, there are features which will be cut in the interest of time, compromise, complexity, and comprehension. I don't see how you avoid that without abandoning the idea of voting altogether, which is something I'm sure we all find value in. Jordan
