Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123074
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-379-gabd37849b7-fm-20240408.001-gabd37849
Precedence: bulk
MIME-Version: 1.0
Message-ID: <2dd7ef64-d1c5-4ed8-964f-b86dba110e0d@app.fastmail.com>
In-Reply-To: <d8a92e7a-539e-4753-bd27-5d59b17779ba@bastelstu.be>
References: <24e4529d-0b75-44de-90ef-34de5dfb1c99@wcflabs.de>
 <278889be-82ab-4827-a9e7-801b5ba2d8f8@app.fastmail.com>
 <45b726f4-8085-43e2-b701-6b35bc249409@wcflabs.de>
 <d8a92e7a-539e-4753-bd27-5d59b17779ba@bastelstu.be>
Date: Tue, 09 Apr 2024 22:12:38 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] RFC [Discussion]: array_find
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Apr 9, 2024, at 7:49 PM, Tim D=C3=BCsterhus wrote:

> However I'm not sure if adding new array functions piecemeal is the=20
> right choice at this point. array_any and array_every are conceptually=20
> very similar to array_find and are missing as well. In fact=20
> array_any($cb, $array) =3D array_find($cb, $array, true) !=3D=3D null =
and=20
> array_every($cb, $array) =3D !array_any($negatedCb, $array), but it wo=
uld=20
> make sense to have them explicitly for clarity of the reader of the co=
de.

We're in a major catch-22, unfortunately.  We know that collections/iter=
ables are long overdue for a rethink, which means small fixes are just m=
aking more work for the future.  Intermediate concepts like the pipe ope=
rator have been rejected.  However, a full rethink is a massive undertak=
ing, and few people want to do that given the entirely unknown odds any =
RFC has.  And a *real* rethink doesn't make sense to do without generics=
, and... yeah.

So I genuinely don't know what to do here, strategically.

>>> 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 s=
ense here.
>>=20
>> 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=20
> semantically true and false feels quite unwieldy with how class / enum=
s=20
> / interfaces are currently organized in the namespace hierarchy.

Point of order: This parameter is *not* semantically true and false.  It=
 is semantically either/or, and we kinda twist sideways to make it look =
like true/false if we squint.  That's actually pretty common in the curr=
ent stdlib, though it's not a good approach.  Hence why I asked about an=
 enum.  I wouldn't expect it to be single-function, though, but to be ap=
plicable for multiple functions.  (I did not go looking to see if such f=
unctions exist.)

> Some of the array functions have paired function with a _key suffix, b=
ut=20
> looking at the docs it appears the difference usually is that they=20
> *operate* on the keys, instead of returning the keys. So I'm not sure=20
> whether adding a array_find_key companion would be confusing or not.

Another alternative is to always return the key, because you can trivial=
ly get the value from the key, but not vice versa.  Of course, the resul=
ting syntax for that is frequently fugly.

$val =3D $array[array_find($db, $array)] ?? some-default;

I don't have a good small-scale solution.

--Larry Garfield