Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102288
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain blueyonder.co.uk designates 80.0.253.68 as permitted sender)
To: internals@lists.php.net
References: <75db877c-ef0b-7d3b-48a8-9879d90352b0@web.de>
 <7052a9c2-7c19-a382-8967-8fda648569df@blueyonder.co.uk>
 <d995c81f-3f51-93b3-d861-20b4462f6891@librelamp.com>
 <76e4744f-6722-ee49-0325-e4433236f1b1@web.de>
Message-ID: <b1a972ee-b1d2-604f-8a00-79a384879697@blueyonder.co.uk>
Date: Mon, 18 Jun 2018 00:59:29 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <76e4744f-6722-ee49-0325-e4433236f1b1@web.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first()
 and array_key_last()
From: spam-free@blueyonder.co.uk (niel)

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