Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82978
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.223.177 as permitted sender)
References: <011801d04a07$83ab1c00$8b015400$@php.net>	<CABDNdAFQsbo-A-gijPCwYDOf3ts-yKpP0tAL--WUaLU26GB-AQ@mail.gmail.com>
	<016f01d04a3a$e9183220$bb489660$@php.net>	<CAESVnVoM7YbmXA8hTG1O66j+6YX3Xx2Q3uj_F=TPjHA4ws=8JA@mail.gmail.com>
	<d8031ce52e9965c789887e8f7b687a4e@mail.gmail.com>	<CAESVnVpA+M6iv_zbDmKTEF8Q1zKjwnbi1ucc=UyuUyRr+X+U3w@mail.gmail.com>
	<022801d04ab1$4a0c47d0$de24d770$@php.net>	<1913e09d7f52541901d8574d2080a63f@mail.gmail.com>
 <CAAyV7nFD=BQ5dBYiKzhbOKTomKmWvruTnb=R_n9mYB-Lz1P9pg@mail.gmail.com>
In-Reply-To: <CAAyV7nFD=BQ5dBYiKzhbOKTomKmWvruTnb=R_n9mYB-Lz1P9pg@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQGD0sLDaA+/0NIeBlQhQC5OtPA/xwHih9+6AanvcsEBj7eMCwEU0CpMAs0H7+gBDwGZjwJNu28fAX8sxVSdHx2oIA==
Date: Tue, 17 Feb 2015 18:11:22 +0200
Message-ID: <7a5d96b34b98ec1f3ee17be7fa6a1e81@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] Reviving scalar type hints
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
> Sent: Tuesday, February 17, 2015 5:48 PM
> To: Zeev Suraski
> Cc: francois@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