Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82990
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.214.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <2CBDEB67-3DE3-437D-9AF3-0E6A92027244@zend.com>
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>
	<7a5d96b34b98ec1f3ee17be7fa6a1e81@mail.gmail.com>
	<CAPhkiZxpYbaPN1370_HFTVnBA=Jg-rU8DrB2P+2dmRcJfGWPtw@mail.gmail.com>
	<2CBDEB67-3DE3-437D-9AF3-0E6A92027244@zend.com>
Date: Tue, 17 Feb 2015 19:22:21 +0200
Message-ID: <CAPhkiZwcD3h42=9eak4uP9n2GBE=v0LVP6Ncq9Oz7L91dJ5y5w@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Reviving scalar type hints
From: narf@devilix.net (Andrey Andreev)

Hi,

On Tue, Feb 17, 2015 at 6:50 PM, Zeev Suraski <zeev@zend.com> wrote:
>
>> On 17 =D7=91=D7=A4=D7=91=D7=A8=D7=B3 2015, at 18:32, Andrey Andreev <nar=
f@devilix.net> wrote:
>>
>> Hi,
>>
>>> On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski <zeev@zend.com> wrote:
>>>
>>> If it gave both sides exactly what they wanted, how come it generated s=
o
>>> much objection?
>>>
>>> Simply put, because it absolutely doesn't give both sides what they wan=
ted.
>>> Many (most?) of those who opposed it opposed it because they believe ma=
king
>>> 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.
>>
>> I agree that it doesn't give everybody what they want - it only gave
>> weak hint supporters *all* that they want.
>
> Andrey,
>
> I'm a weak typing supporter;  I want PHP to never make it easy at the lan=
guage level to treat "32" and 32 differently;  The RFC did exactly that.
>

Yes, I already know that.
The difference, and why I keep pointing that out, is that me and many
others want strict typing for our own reasons (but still in its
entirety instead of as a limited mode) and most of us don't even care
if you getting weak typing for your own usage. You can't work towards
consensus if your target is to prevent the opposing group of getting
what they want. I see both as valuable tools for different jobs and I
want to have more tools at my disposal, while you're trying to tell me
that I should use only one tool for everything.

> -> The v0.3 RFC didn't give weak hint supporters everything they wanted. =
 QED.
>
>> Many also objected because strict typing was only opt-in and could
>> never affect the caller's code unless the caller explicitly declares
>> that they want to do that. You're ignoring that and you're twisting it
>> the other way around.
>
> It's enough to provide one counter example to disprove an assertion - the=
 assertion that the v0.3 RFC gave everyone what they wanted - and I provide=
d the one I can personally attest to.  I certainly didn't claim strict typi=
ng supporters got everything they wanted, so I'm not sure why I'm twisting =
anything.  If anything, you're only making the point that the v0.3 RFC does=
n't give everyone what they want stronger.
>

Yes, I am making the point stronger.

But you implied that most objections were from people who don't want
strict typing in PHP at all. And I disagree with that because it's a
speculation, which in turn you are using to favor your weak-hints-only
case (hence, twisting it in another direction).

> I think the options we're discussing here take us away from this zero sum=
 game, provides benefits to both schools of thought, and it seems to me as =
if you were open to it.  I'd much rather we invested our energies there!
>
> Zeev

Cheers,
Andrey.