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
