On Sat, Dec 26, 2020 at 10:02 AM Niklas Keller <m...@kelunik.com> wrote:
>>
>> I want to re-iterate my opinion on this discussion thread: anything
>> with a prefix is a hard-no from me. Namespaces are literally designed
>> for this, and I will not vote "yes" to `iter_all`, `iterable_all`,
>> etc, no matter what the prefix is. Anything without a namespace is a
>> no from me.
>>
>> I'm flexible on many other points, but not this one. It's 2020 (almost
>> 2021); let's use namespaces for what they were designed for. This is a
>> perfect opportunity; they work on more than just arrays so using the
>> `array_` prefix for consistency doesn't apply.
>
>
> Hey Levi,
>
> while I agree that namespaces were designed for this, I think `all` and `any` 
> are too generic names, even in a namespace.
>
> I think Java's naming with any_match / all_match could be a good fit.

I agree they are a bit generic, especially because we may need to
distinguish between keys and values. For that reason I prefer
`Spl\all_values` and `Spl\any_value`. We can make it read very well
with named parameters if that's your thing:

```
if (all_values($input, 'is_int'))
// or alternatively:
if (all_values(of: $input, satisfy: 'is_int'))
```

I wouldn't put too much excitement into making highly readable
English; I mention it mostly to point out that I think we should put
at least a little bit of effort into parameter names for any new
library additions.

> If promises / futures make it into core in the future, there will be a need 
> for an `any` / `all` function combining promises / futures.
>
> Maybe these should be named `array_*` and all array functions should be 
> adjusted to work with iterators?

Many of them can't work efficiently on iterables or have
idiosyncrasies. I don't think this the way forward either.

-----

I am hopeful we can add at least a few other functions alongside these
additions to help establish good patterns for functions that work with
iterables, as there are quite a few of them. At least we should add
some form of `reduce`, as `any` and `all` are forms of reducers.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to