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.godj...@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 <i...@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 <z...@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
>
>
