Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111764
MIME-Version: 1.0
References: <DM6PR07MB6618683DF0ABBA43C4FC7CB8F9510@DM6PR07MB6618.namprd07.prod.outlook.com>
 <CAF+90c-OC8MC9U9GUkctizWVDPnVjuA6nibWgnV8c1Whyw+wLw@mail.gmail.com>
 <CADyq6sJ63C4Xy1scMbZFnwnxnsqPe5uumbbnPYhhrNe5+NNxjQ@mail.gmail.com> <CAJvSBVPckeWuQHw98=y48u_O1Pmhr=ET6w3Ki_MgaM-UWw0_zQ@mail.gmail.com>
In-Reply-To: <CAJvSBVPckeWuQHw98=y48u_O1Pmhr=ET6w3Ki_MgaM-UWw0_zQ@mail.gmail.com>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Tue, 1 Sep 2020 09:05:29 -0600
Message-ID: <CAAKU0u=fXEUJLC7Xxs_aWZoqBBUzk0-Vhk3ThQaQCAscGWeAVw@mail.gmail.com>
To: Peter Bowyer <phpmailinglists@gmail.com>
Cc: Marco Pivetta <ocramius@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	tyson andre <tysonandre775@hotmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] Global functions any() and all() on iterables
From: internals@lists.php.net ("Levi Morrison via internals")

On Tue, Sep 1, 2020 at 2:08 AM Peter Bowyer <phpmailinglists@gmail.com> wrote:
>
> On Tue, 1 Sep 2020 at 08:59, Marco Pivetta <ocramius@gmail.com> wrote:
>
> > Did the namespaces ship sail forever? Can we just have those instead,
> > please?
> >
>
> To mix metaphors: it sailed, shot down in fiery flames.
>
> Unfortunately.
>
> Peter

If we add significantly more functions to the proposal (which makes it
riskier from a time investment standpoint), then I think the case for
a namespace makes sense. Nobody wants to add a namespace for one or
two things. If there are 10+ things it's a bit more convincing. This
is a case where having a proposed API and impl in PHP-land is probably
sufficient enough to make an RFC vote; the conversion to C can happen
if it passes.

Here is a sampling of functions from my own (private) iterable library:

  - all_values
  - any_value
  - no_value
  - one_value
  - to_iterator
  - filter_values
  - for_each_value
  - map_values
  - reduce_values
  - zip_values

The values suffix is because there are variants that work with more
than just the values. Being value-centric is great, but we must leave
design room for the rest for when they are needed.

Anyway, the key point I'm making is that I think a larger RFC has a
better shot of passing if we want to namespace it.