Re: Type hinting

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 > >