Re: [RFC] Global functions any() and all() on iterables
| From: | Levi Morrison via internals | Date: | Tue, 01 Sep 2020 15:05:29 +0000 |
| Subject: | Re: [RFC] Global functions any() and all() on iterables | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-111764@lists.php.net to get a copy of this message | ||
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.