On 21/10/14 02:17, Andrea Faulds wrote:
> JavaScript returns NaN here and C sets errno to an error value. PHP uses 
> FALSE, in some respects, like JavaScript uses NaN.

Isn't part of the problem here that we DO need more than a single return
in many places. Even 'bool' can be thought off as three states, TRUE,
FALSE and 'not set' which would be NULL in an SQL context. I've always
worked with '0' being false and anything else true unless the value is
not set.

The first part of the jigsaw here is solving the debate between errors
and exceptions. Both provide a different method of working and a
different workflow. Those who are happier throwing exceptions everywhere
need a different solution to those who prefer to handle the answer to a
question at the time it is raised?

It depends on the answer needed here just what error is returned,
to_int('string(4) “10.0”') failing is wrong in my book since '10' IS a
lossless result here. "10.1" would be a different case and in this
example one needs an is_int() function that gives a bit more than
yes/no. IF a cast has failed and it was important to know why it has
failed then to_int has to be prefaced with checks which would remove the
need to use to_int at all, since (int) would be fed with a valid value.
Calling to_int and getting '0' back may be a valid return in my book so
how do I know if the '0' is because that is the real answer or a failed
conversion? I need a separate 'not valid' return somehow which IS either
an exception, or a previous action which avoids the question.

As Stas is saying ... Do we need another incomplete way of asking the
question. Would it not be better to tidy up what we have to give the
right answer in a way that suits each method of working?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to