On Tue, Apr 9, 2024, at 7:49 PM, Tim Düsterhus wrote: > 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.
We're in a major catch-22, unfortunately. We know that collections/iterables are long overdue for a rethink, which means small fixes are just making more work for the future. Intermediate concepts like the pipe operator have been rejected. However, a full rethink is a massive undertaking, 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 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. 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 current 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 applicable for multiple functions. (I did not go looking to see if such functions exist.) > 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. Another alternative is to always return the key, because you can trivially get the value from the key, but not vice versa. Of course, the resulting syntax for that is frequently fugly. $val = $array[array_find($db, $array)] ?? some-default; I don't have a good small-scale solution. --Larry Garfield
