On Monday 24 May 2010 12:09:30 am Zeev Suraski wrote: > I have to say that I don't really see the logic in "either it should > be identical to PHP's conversion rules or it should be 100.000% > different (strict)". Adding strict typing would be the largest > inconsistency in PHP's core syntax, ever. > > For that reason, I prefer pretty much any variation of the proposed > solution over strict type checking. > > I see three key options going forward: > 1. Implement the table along the lines of what it looks like now, > perhaps with minor changes. > 2. Implement identical conversion rules to the ones that exist in > PHP; That effectively turns type hinting into scalar casting > operators (not saying that's a bad thing!) > 3. Implement identical conversion rules to the ones that exist in > PHP, except for when they really suck. Namely, lose the > array->scalar conversions and silent conversions of non-numeric > strings to numbers. > > I personally lean towards #3. > > Zeev
#3 is the one that seems like it would be most useful in practice, with one caveat. If given an input of float(5.4) and a function parameter specified as int, there is data loss if you just do the equivalent of (int)$foo so that falls into the "really suck" category and should also explode. (float(5), however, has no data loss in that operation so it's safe.) I don't know if there's performance issues to address with that addition that may nix it, but that would be the ideal. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
