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
