On Thu, Feb 26, 2015 at 3:15 PM, Zeev Suraski <z...@zend.com> wrote: > > -----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. >
Yes, the database use case and exterior data has been my main concern over the type hint proposals. Now, this could also be changed (fixed, etc) on a different layer (aka database extensions to deal with native types) but that is likely far more to bite off than one would want at this point. It is relatively painless to go in and cast all of those types but the amount of code out there which people are going to just 'expect' this to work will be fairly large and one of those cases that will possibly be cause for migration concerns. > > 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? > Yes, direction is less of an issue.
