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
