Zeev,
I missed the initial replies to this, just had a quick read through (of
the kind you have first thing on a Monday morning).
Essentially the problem is this:
> My point is that we can do the very same optimizations with coercive
types as well - basically, that there is no delta.
The problem is that an implementation that has to care about coercion,
one that has to care about nonsense input, has to generate considerably
more complex code, to manage that input or perform those coercions.
You may be able to perform some of the same optimizations, but the code
executed at runtime is going to be more complex to execute and to generate,
that is obviously true.
The JIT Zend had needed to generate similarly complicated code and *it
was not faster than PHP, in the real world*, we are told.
I'm not sure what you are arguing about, there is no point in generating
any code that is not faster than Zend, and Zend just got a bunch faster.
I'm not sure if I have said the right words to make you see the other
point of view, if I haven't then I don't know them.
Cheers
Joe
On Mon, Feb 23, 2015 at 2:59 AM, Jefferson Gonzalez <jgm...@gmail.com>
wrote:
> 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.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
