On 17/06/18 23:09, Enno Woortmann wrote:
Hi Alice,
Am 17.06.2018 um 22:16 schrieb Alice Wonder:
boolean is a value, null is the absence of a value, which is more
accurate, no?
In my opinion that's the argument to return null for either parameters
which aren't an array or empty arrays simply because a first/last key
isn't present and null is the value to be returned for an undefined state.
I've tested this behavior with other array_* functions which are
provided in the PHP core and they provide null consistently, eg.:
root@WOL-Soft-DEVVM:/var/www/WOL-Soft# php -r "var_dump(array_keys(1));"
PHP Warning: array_keys() expects parameter 1 to be array, integer
given in Command line code on line 1
NULL
root@WOL-Soft-DEVVM:/var/www/WOL-Soft# php -r
"var_dump(array_values('hello'));"
PHP Warning: array_values() expects parameter 1 to be array, string
given in Command line code on line 1
NULL
root@WOL-Soft-DEVVM:/var/www/WOL-Soft# php -r "var_dump(array_flip(null));"
PHP Warning: array_flip() expects parameter 1 to be array, null given
in Command line code on line 1
NULL
There was another remark which wasn't sent to the internals mail list
but to my personal mail account (mehh :( ) which supported to return false:
"because a lot of functions act the way returning false when things go
wrong even when they normally only would return string/int/array which
should be justification enough: consistency"
An example for this argument was the function strpos which may be
checked with === or !== against false.
But the real discussion about the return value and the facility of
comparison against another value is only interesting if we extend the
scope of this RFC to cover also array_value_(first|last), as null as an
array key is not supported and will be casted to an empty string. Due to
this internal handling of array keys, null is for the functions
array_key(first|last) an unique return value to evaluate failures.
My opinion about this subject supports your argument as null is the
value which should be returned if the requested value is not defined. If
a variable which is neither an array nor an array with entries is passed
neither the first/last key nor the first/last value is a defined value
and thus null should be the return value.
Especially if we decide to extend the scope of this RFC to cover also
array_value_(first|last) there is no possibility to provide a return
value which doesn't collide with a possible array value. If cases occur
which may resolve into a collision, the usage of functions like
is_array() and empty()/count() is inevitable as both null and false are
valid values for an array value. To argument with the semantic of false
and null the correct return value should be null for each of the
proposed functions (as well the proposed functions which are currently
covered by the RFC as the extended version which also covers the methody
array_value(first|last) ) as null defines an undefined value.
Regards,
Enno
Hi, I didn't reply to your question as to why I thought false would be a
better return value for non-array, as I thought Reindl covered my
feelings completely.
Given the points made by Alice and yourself I've reconsidered 'false'
being a better choice than 'null', as it might be a valid return value
from the array.
However my main concern that a non-array variable or a non-existent
value, are an error and need to be handled appropriately, has not
changed. IMO, a notice/warning does little to nothing in helping the
programmer determine the problem and track down the cause. Which leaves
one having to wrap these functions in 'if (is_array($var) &&
!empty($var)) {...}' to prevent the possibility.
Niel
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
