Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variation_001.phpt

Hi Johannes,

Johannes Schlüter wrote:
> Hi,
> 
> On Mon, 2009-03-16 at 09:52 +0000, "Dmitry Stogov" wrote:
>> Log:
>>   Fixed bug #47664 (get_class returns NULL instead of FALSE)
> [...]
>> @@ -716,7 +716,7 @@
>>         int dup;
>>  
>>         if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|o",
>> &obj) == FAILURE) {
>> -               return;
>> +               RETURN_FALSE;
>>         }
> 
> Usually we return NULL in case parameter parsing fails, this is
> documented like this:
> 
>    If the parameters given to a function are not what it expects,
>    such as passing an array where a string is expected, the return
>    value of the function is undefined. In this case it will likely
>    return NULL but this is just a convention, and cannot be relied
>    upon.
>    http://www.php.net/manual/en/functions.internal.php
 >
> This also applies to many other functions which usually return "false"
> on error and are documented like that. Therefore I think returning NULL
> in this case is a good thing in order to bring more consistency to the
> language and I think this BC break is quite minor.

I don't think changing of documented behaviour in minor version makes 
sense. And I don't see a lot of consistency in returning NULL in case 
each function documentation doesn't say it.

Really, I would prefer special kind of exception.

Thanks. Dmitry.

> On a sidenote: There are cases where such a change has bigger effect: In
> all cases where int(0)/string("") are "successful" return values and one
> has to use type-safe comparison (think about strpos for instance) but in
> this case I see more of a cleanup. Oh and the user should, usually,
> check the types before passing the variable to the function ...
> 
> johannes
> 
>