Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113110
MIME-Version: 1.0
References: <DM6PR07MB66189594D6D3B6D820E4A5FBF98F9@DM6PR07MB6618.namprd07.prod.outlook.com>
In-Reply-To: <DM6PR07MB66189594D6D3B6D820E4A5FBF98F9@DM6PR07MB6618.namprd07.prod.outlook.com>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Mon, 8 Feb 2021 08:08:00 -0700
Message-ID: <CAAKU0ukKrfr54w-3NHiJRUtRgkptgnw8vb7QXvHXQhNbbcFhMg@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [VOTE] PHP\iterable\any() and all() on iterables
From: internals@lists.php.net ("Levi Morrison via internals")

On Mon, Feb 8, 2021 at 7:33 AM tyson andre <tysonandre775@hotmail.com> wrote:
>
> Hi internals,
>
> Voting has started on https://wiki.php.net/rfc/any_all_on_iterable and ends on 2021-02-22.
>
> This RFC proposes to add the functions `PHP\iterable\any(iterable $input, ?callable $callback = null): bool` and `PHP\iterable\all(...)`
> to PHP's standard library's function set, using the namespace preferred in the previous straw poll.
>
> There is a primary vote on whether to add the functions, and a secondary vote on the name to use within the `PHP\iterable` namespace.
>
> Thanks,
> - Tyson
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Thanks for the RFC. I have voted no, even though I am very supportive
of the direction. My objections are:
- I think the scope is too small. This is introducing a new family of
functions, but is only proposing two functions. This is too small to
firmly root in good design and precedence.
- I do not like the chosen namespace. This is not as important as the
previous point, but still factored into my decision as we are still
very early in choosing namespaces for internals. I don't want to vote
for something I think is a bad direction when we're this early on.

Again, I am supportive of adding these functions in some form, but I
very strongly do not believe this RFC is what we should do.

I tried to collaborate with Tyson more on these points but either we
mis-communicated or he wasn't interested. In any case, it's up for a
vote so I choose "no."