Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123071
Message-ID: <d8a92e7a-539e-4753-bd27-5d59b17779ba@bastelstu.be>
Date: Tue, 9 Apr 2024 21:49:43 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] RFC [Discussion]: array_find
To: =?UTF-8?Q?Joshua_R=C3=BCsweg?= <josh@wcflabs.de>,
 Larry Garfield <larry@garfieldtech.com>,
 PHP internals <internals@lists.php.net>
References: <24e4529d-0b75-44de-90ef-34de5dfb1c99@wcflabs.de>
 <278889be-82ab-4827-a9e7-801b5ba2d8f8@app.fastmail.com>
 <45b726f4-8085-43e2-b701-6b35bc249409@wcflabs.de>
Content-Language: en-US
In-Reply-To: <45b726f4-8085-43e2-b701-6b35bc249409@wcflabs.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 4/7/24 21:10, Joshua Rüsweg wrote:
> On 07.04.24 16:35, Larry Garfield wrote:
>> 1. Should this work on arrays or iterables?  This is a long standing limitation of PHP.  The array operations don't work on iterables, even though we've had iterables for 20 years.)
> 
> In the longer term, it definitely makes sense to create a separate API
> here that can handle not only arrays, but iterables in general. I have
> heard this suggestion in various places (including in the mailing list)

For reference: https://externals.io/message/118896#118896

> and had also looked into it in the process of this RFC, but did not
> pursue it further after the initial idea, as it would be important for
> me that such an API is planned accordingly and has an appropriate
> repertoire right from the start (functions such as map, filter, find,
> push, pop, …). In my opinion, a single function would be very out of
> place, especially if this API is then really soon tackled and then
> possibly differs from the implementation of the RFC.

It makes sense to me to not make `array_find` the “odd one out” and 
widening all the array_* functions probably would not work well, because 
either the Iterator is converted into array, nullifying the benefits of 
using an Iterator or the return type needs to be changed, making the 
signature confusing without generics.

That said, adding a “find” function makes sense to me and the 
implementation looks reasonable.

However I'm not sure if adding new array functions piecemeal is the 
right choice at this point. array_any and array_every are conceptually 
very similar to array_find and are missing as well. In fact 
array_any($cb, $array) = array_find($cb, $array, true) !== null and 
array_every($cb, $array) = !array_any($negatedCb, $array), but it would 
make sense to have them explicitly for clarity of the reader of the code.

>> 2. Key handling.  It's good that you have looked into this, because I was going to mention it. :-)  However, I don't think a boolean is the right answer, since the question is binary, not true/false.  (Those are not the same thing.)  I think a small return-mode Enum would make more sense here.
> 
> I like the idea, thank you! However, I am unsure whether an additional
> enum for the function would not be too much overhead.

I feel the same. Adding an enum for each binary parameter that is 
semantically true and false feels quite unwieldy with how class / enums 
/ interfaces are currently organized in the namespace hierarchy.

Some of the array functions have paired function with a _key suffix, but 
looking at the docs it appears the difference usually is that they 
*operate* on the keys, instead of returning the keys. So I'm not sure 
whether adding a array_find_key companion would be confusing or not.

Best regards
Tim Düsterhus