this is more or less true. :( The proposal is presented in an unfair way to include strict typing without the ability to vote for weak types only.
Despite of semantic arguments, the implementation is a bit immature and introduces slowdown for any code without type hints. Thanks. Dmitry. On Mon, Feb 9, 2015 at 7:20 AM, Matthew Leverton <lever...@gmail.com> wrote: > On Sun, Feb 8, 2015 at 3:22 PM, Zeev Suraski <z...@zend.com> wrote: > > I'm well aware of it as I wrote that policy. The goal of the policy was > to > > prevent a situation where a temporary majority can introduce features > into > > the language that would later on be impossible to reverse. It's not by > any > > stretch a good mechanism to solve controversial votes, which again, > should > > ideally be avoided as much as possible. It's just that there isn't a > better > > mechanism. > > > I know I'm unfairly paraphrasing you, but it sounds like you are > saying that for things that you don't have strong feelings about, then > you're fine if the others vote amongst themselves. But for things that > matter to you, you want to reserve the right to prevent change. Is > there a way to fairly describe what you consider too controversial to > vote on? > > The problem I see with votes for this type of feature is that you > probably have a breakdown of something like: > > - 10% of people don't want scalar type hints > - 20% of people want both, but 50% of them would vote for either weak or > strong > - 35% of people want strict, but 80% of them are fine with weak > - 35% of people want weak, but 80% of them are fine with strong > > So if a strict-only vote happens first, you get 73% to say yes. If > weak-only vote happens first, you get 73% to say yes. > > (I'm obviously just making up these numbers with no scientific basis, > but I think the principle is valid.) > > The only way to be fair IMO is to hold a vote where you rank those > four options (weak, strong, both, neither) and hold an instant run-off > vote where the first majority wins. And if 'neither' wins, then agree > that the topic cannot be revisited until next major version, so that > everybody can rest for 5 years. ;) > > -- > Matthew Leverton > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
