Re: Type hinting

Because auto-conversion is magic and like any magic causes in-consistent behaviour and what I like to call WTF factor, which means the developer is not quite certain what is going on. With strict type hints the behaviour is consistent every-time and there is no ambiguity of function. On Thu, May 27, 2010 at 7:03 AM, Arvids Godjuks <arvids.godjuks@gmail.com>wrote: > 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 > >> > >> > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >