Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83536
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.48 as permitted sender)
Message-ID: <54EA97A2.4010701@gmail.com>
Date: Sun, 22 Feb 2015 22:59:46 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Zeev Suraski <zeev@zend.com>, Jefferson Gonzalez <jgmdev@gmail.com>
CC: PHP internals <internals@lists.php.net>
References: <2e4694f9805ee81ea0b2c79eab06c2d6@mail.gmail.com>	<CAAyV7nExeZ1xouJAsACm9AvAGuQw0e-0FgVdEOAyzsC5OEn5_Q@mail.gmail.com>	<54EA5EDA.8010605@gmail.com>	<CAAyV7nFt3KL_uH4HuA5xQ7HY+3_3=fq=pg0_U1aMrdirETC6LQ@mail.gmail.com>	<54EA6A99.5010609@gmail.com> <CAAyV7nE2Cfr0ohpPnXWnf5agmyGfeirNH-3UGyHEhsDaMvmsoQ@mail.gmail.com> <54EA7F15.9030606@gmail.com> <54EA891B.6030405@gmail.com> <09b9ee836c04b1750614a91bd39a5bed@mail.gmail.com>
In-Reply-To: <09b9ee836c04b1750614a91bd39a5bed@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
From: jgmdev@gmail.com (Jefferson Gonzalez)

On 02/22/2015 10:06 PM, Zeev Suraski wrote:
> One key premise behind both strict type hinting and coercive type hinting is
> that conversions that lose data, or that 'invent' data, are typically
> indicators of a bug in the code.
>
> You're right that there's no risk of a segfault or buffer overflow from the
> snippets you listed.  But there are fair chances that if you fed $x  into
> round() and it contains "whats cooking" (string), your code contains a bug.
>
> Coercive typing allows 'sensible' conversions to take place, so that if you
> pass "35.7" (string) to round() it will be accepted without a problem.
> Strict typing will disallow any input that is not of the exact type that the
> function expects, so in strict mode, round() will reject it.  The point that
> was raised by Stas and others is that this is likely to push the user to
> explicitly cast the string to float;  Which from that point onwards, happily
> accept "whats cooking", keeping the likely bug undetected.

Thats true, but I think where most problems will rise is when dealing 
with user input, example:

Good url
myurl.com/?id=10

Bad url
myurl.com/?id=somehing+else

So in the url example neither coercive or strict are safe, IMHO you as a 
developer should analyze the input and decide what to do if the value 
isn't of an expected type.

On strict you as a developer decide if casting is an accepted behavior, 
like when dealing with database output which may return values as 
string, or reading from config files, but you know the value is (int) 
compatible, so the casting is safe. Besides, in the v0.5 STH RFC the 
strict mode is optional.

I think both RFC's should join, dual mode coercive/strict :), but I 
guess that will not be possible until Anthony convinces the coercive 
camp how strict could be used to do better optimizations. Unless it 
happens the other way around and is proved with code/patches that same 
level of optimizations can be reached with coercive.

Anyway I just hope for scalar type hints, not just to improve code 
reliability, but also to gain some performance out of it. At the end I 
wish the best option is implemented since this is a really impacting 
feature for the future of the language.