Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120510
Message-ID: <bdfab624-3854-b45a-98dc-1b1a5d5b9f7b@fide.pl>
Date: Fri, 2 Jun 2023 10:57:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.11.2
To: internals@lists.php.net
References: <97308c1d-e9f0-e28d-78ba-11da2a136ee6@fide.pl>
 <6c66ad82-7616-4b22-8961-494b557a3def@app.fastmail.com>
Content-Language: pl
Organization: FIDE.pl
In-Reply-To: <6c66ad82-7616-4b22-8961-494b557a3def@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Proposal: addition of array_find() and array_find_key()
 functions
From: janusz@fide.pl (Janusz Szczypka)

W dniu 2.06.2023 o 02:14, Casper Langemeijer pisze:
> On Thu, Jun 1, 2023, at 18:02, Janusz Szczypka wrote:
>> array_find(): This function would allow developers to find the first element in
>> an array that satisfies a specific condition. The condition would be defined by a callback function.
> This would actually be an alternative to a simple foreach() with an if() and a break. As your example implementation makes clear.
>
> array_find() and array_find_key() would still do the same internally, but add a function call adding the overhead of pushing parameters to stack, switching the scope, passing return value back switch scope and pop from the callstack again. If parameters or return value are typed this adds even more overhead.
>
> I don't think there is any optimisation possible when this is done in C.
>
> To the proposer it probably feels that this is an array function currently missing, but instead it's probably better not to have array_find() because people might actually use it for larger datasets.
>
> Although I acknowledge that it will reduce the number of lines of PHP code it doesn't actually reduce the mental capacity to read and maintain code. I find the simple elemental building blocks of loops, conditionals and expressions easier and more expressive. In my experience this is especially so for less experienced developers.
>
> Then there is a problem of naming. array_search() and array_find(). To a new developer, how would they know which is which?
>
> Also there is the missing array_find_value_and_key() method. Because why should we be limited to either matching the key OR the value?
>
Hi,

You are right about speed penalty for using those functions over simple 
loops, however if we would stick to that point of view, we should 
deprecate and remove array_filter, array_map, array_walk, array_u...

Proposed functions are not intended for developers working on large 
arrays with speed constraints, but for simple usecases where (at least 
for some people) readability will be improved by reducing 6 lines of 
code to just 1.

"find" is consistent with names of the same function in other languages 
as Tim has pointed in his email yesterday.

I leally do not see many uses for array_find_value_and_key, however - as 
I you can see in my example implementations - condition is only checked 
for the values of the array. We could have a nice family of 
array_find_... functions including adding array_find_by_key and 
array_find_key_by_key, array_find_by_value_and_key and 
array_find_key_by_value_and_key... ;) or better discuss whether we 
should pass both key and value to callback like below (order of the 
arguments for the callback is to be discussed) or use flags like in 
array_filter to decide what do we want to pass

function array_find(callable $callback, array $array)
{
     foreach ($array as $key => $value) {
         if (call_user_func($callback, $value, $key) === true) {
             return $row;
         }
     }
     return null;
}

vs

function array_find(callable $callback, array $array, int $mode = 0)
{
...
}

Best regards,
Janusz