> -----Original Message----- > From: Mike Willbanks [mailto:pen...@gmail.com] > Sent: Thursday, February 26, 2015 10:43 PM > To: Zeev Suraski > Cc: PHP Internals > Subject: Re: [PHP-DEV] A different user perspective on scalar type > declarations > > Here is the most basic example and something that people are going to > often > run into. You see this type of code with hydrators, mappers, etc. > Ultimately > the end result is going to be the same: > > https://gist.github.com/mwillbanks/04e3be68f737c25984ab > > I'm not certain if there is a need to explain that bit a bit more. But a > string > "1" as a bool should work as with a string "0". For instance, today we > have > the following for both string's 0 and 1: > > $bool = "0"; > > var_dump($bool); // "0"" > > var_dump($bool == false); // true > var_dump($bool == true); // false > var_dump($bool == 0); // true > var_dump($bool == 1); // false
OK, so essentially you're saying that you expect "1" and "0" to be coerced into booleans. This is something we've been wondering about in the Coercive RFC, and in the original version we allowed all scalars to be coerced into bool - but not the other way around. Right now the RFC only allows for integer->bool coercion, but the database use case seems to be a pretty strong one. The options we considered were int only, int+string or none at all. Float is the one that really stands out as pretty meaningless. I think the opposite side is a lot trickier - converting from bool into string (or any other scalar type for that matter) is quite likely to hide bugs. We've found a bunch of bugs like that today, where return values of strpos() are fed without validation into other APIs that expect an offset, and similar use cases. Such code patterns are bound to be hiding bugs, at least in some cases. I'm guessing that direction is less of an issue in your mind, correct? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
