> -----Original Message----- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Tuesday, February 17, 2015 5:48 PM > To: Zeev Suraski > Cc: franc...@php.net; Sara Golemon; PHP internals > Subject: Re: [PHP-DEV] Reviving scalar type hints > > Zeev et al, > > Because it > **wasn't** a compromise (neither side had to give up anything). It gave > both > sides exactly what they want and need while letting them work together > transparently.
If it gave both sides exactly what they wanted, how come it generated so much objection? Simply put, because it absolutely doesn't give both sides what they wanted. Many (most?) of those who opposed it opposed it because they believe making zval.type as prominently available as the RFC did is bad for PHP. Consequently, this whole 'adding both gives everyone what they want' is simply wrong. It's not unique to this RFC either; There's a reason we don't accept all proposals, including countless ones that have zero compatibility/performance issues, just because we don't think they're a good fit for the language. Regarding your point about static analyzers, based on what I saw on this list it hardly seems that this is the main reason most proponents of strict types are interested in them. I, for one, think developer productivity is a lot more important than making life easy for static analyzers, and static analyzers should be designed around the language, not vice versa. I urge you to consider the fact that the solution that 'gives everyone what they wanted' is hardly that at all, and we're trying to find a potential compromise that will hopefully have a lot fewer people objecting to it. If we succeed, not everyone will get everything they want, but hopefully a lot more people will be able to join the yes vote. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
