Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112752
MIME-Version: 1.0
References: <DM6PR07MB661827026586104D5DEDAA64F9C20@DM6PR07MB6618.namprd07.prod.outlook.com>
 <CAAKU0ukPqFrEC2qUXOAL7T8wRcfonWiA8HQdckC7GuMYTOBC6g@mail.gmail.com> <CANUQDCg_ixVeYyB52s0Gc0GNPDvPDuWa62yNxYo+-Jsa+geuCg@mail.gmail.com>
In-Reply-To: <CANUQDCg_ixVeYyB52s0Gc0GNPDvPDuWa62yNxYo+-Jsa+geuCg@mail.gmail.com>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Mon, 4 Jan 2021 10:27:43 -0700
Message-ID: <CAAKU0ukHaz3yH0NyW8YLJrkbQGPuD8Q0dqbhRWb-yQhZLDos6w@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: tyson andre <tysonandre775@hotmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Straw poll: Naming for `*any()` and `*all()` on iterables
From: internals@lists.php.net ("Levi Morrison via internals")

On Sat, Dec 26, 2020 at 10:02 AM Niklas Keller <me@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.