Re: Type hinting

Why not do the check and let auto converting for int => float, int => string, string => int, string => float when it doesn't loose any precision. 2010/5/27 Ilia Alshanetsky <ilia@prohost.org>: > Zeev, > > Auto-conversion does not validate input to the function/method, it merely > obfuscates the "wrong" input by converting it to desired type resulting in a > potentially un-expected value. I must say I am completely against the > auto-conversion hint idea. > > As far as your example goes consider a function that expects a boolean, but > instead gets an int/string/float, which in nearly all cases will result in > TRUE. Which is not the desired outcome. > > On Thu, May 27, 2010 at 1:42 AM, Zeev Suraski <zeev@zend.com> wrote: > >> At 00:28 27/05/2010, Davey Shafik wrote: >> >>> You could just as easily say to do: >>> >>> function foo($bar) { >>>        $bar = (int) $bar; >>> } >>> >>> as: >>> >>> function foo($bar) { >>>        if (!is_int($bar)) { >>>                // error >>>        } >>> } >>> >>> Why bother with either if that's the case? >>> >> >> I don't think there's any argument that what we're proposing to add to the >> language can already be done using existing functionality.  That's true >> whether we're talking about strict type checking, auto-converting type >> hinting, or pretty much any other idea we might come up with. >> >> There are several reasons we still want to add this feature - reducing the >> burden of validating input, making it clearer to the user what the function >> expects (from the API), and in the future - it might allow for certain >> optimizations. >> >> When we come to evaluate which solution we should pick, we should go for >> the solution that is the most consistent with the rest of the language and >> that gives us the most bang for the buck.  Auto-converting type hinting >> falls in that category - it's the most consistent with the rest of the >> language, and it's the most useful behavior in the vast majority of cases - >> it stands a chance to become widely used.  For every case where you'd >> explicitly care about the zval.type (such as when you need to differentiate >> between false and zero), you'd have dozens of cases where you won't.  Adding >> language level support for those rare cases simply doesn't make sense.  The >> marginal gain is minimal.  The added complexity and confusion is very high. >> >> I'm strictly against having two solutions.  It's the worst outcome we could >> reach IMHO - it means we're unable to decide which is better, so we support >> both (kind of like a hi-tech version of >> http://bit.ly/9I8dHw). I think >> it's the one solution that's worse than implementing strict typing only - it >> does mean that I would actually support having strict typing only over >> having both.  Still, I think having auto-converting type hints is by far the >> best solution. >> >> Can anybody share with us *common* cases where strict typing would be >> necessary, and the proposed auto-converting type hints won't do? >> >> Zeev >> >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >