Hi! > We discussed it a year ago, and discussion died down to nothing (possibly > because it was sidetracked); If there are no objections I'll bring it to > vote in the coming days ...
I tend to agree with the sentiment, but not 100%. I think there are two kinds of changes - one kind is more fundamental than the other. I.e., if we add a major feature to the language (like strict type checks, for example) it is going to have major influence on the language and virtually everybody using it. You can't just ignore it. This also goes to changes which alter ways that the syntax works, etc. which have potential to break existing code (even if it's bad code, still). Then there are more "neutral" changes - like adding an utility function or an option to a function. PHP has a lot of "syntax sugar" functions and sometimes even "kitchen sink" functions - ones that most people don't use but some do. Having one more would not be that big of a deal - that's where, unlike the above, "what you don't use doesn't hurt you" is true. You probably have guessed already what I am getting at - the second kind is probably OK to have 50%+1, since people that don't need this option/function can vote no but still we can have it if more people do. The counter-argument could be that people that don't need it can just avoid voting, but then we don't have clear boundary between "I don't think it's useful for enough people to add it" and "I am on vacation and haven't bothered to even have an opinion". That said, I'd love to see how many of the accepted RFCs we have now were actually accepted by margin between 50%+1 and 2/3 and what they are, if the number is very low maybe it's irrelevant. Unfortunately I don't have time to do it myself soon, but it would be super-awesome if somebody did. P.S. The question of quorum is interesting to explore, though I am not sure how we figure out the numbers. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
