At 14:20 31/12/2009, Derick Rethans wrote:
On Thu, 31 Dec 2009, Stanislav Malyshev wrote:

> > Would changing the returning value to Null to indicate invalid
> > arguments (or any other error condition) would create a significant BC
> > surely? Just how many functions are documented with the entity
> > &return.falseforfailure;? (198 files using this so far vs Return
> > &null; which is used very rarely).
>
> There are different kinds of failure. There's failure for the function (i.e.
> function tried to do something and failed, like couldn't open the file) and
> failure where function wheren't even executed (like you called fopen without > giving it a filename). Some functions return the same in both cases, some do
> not. I'm sure half of the functions documented as &return.falseforfailure;
> return NULL on incorrect args.
>
> As for BC - it may break some scripts that don't check properly but having
> each function do different thing is worse, since you couldn't even write a
> proper check - since you have no way of knowing what to check for.

Hmm, I don't actually think many people test whether parsing parameters
failed, but they do test the return value. AFAIK, our "standard" is to
return NULL for parameter parsing failures (at least that's what all the
examples in README.PARAMETER_PARSING_API do). I'd like to see that be
the case for all things, but changing it now could be quite a bit of a
BC break.

I agree. The real problem is we'd be breaking applications that are in fact checking the return values very properly - as properly as they can according to the documentation. Many functions can return values that are evaluated as boolean false, well as false/null to indicate error; That results in === being used to check the return value, and consequently changing from false to null or vice versa would break the code. Some pedantic users probably use === even if the function can't otherwise return a value that evaluates as boolean false.

Zeev

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

Reply via email to