Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111814
MIME-Version: 1.0
References: <DM6PR07MB6618683DF0ABBA43C4FC7CB8F9510@DM6PR07MB6618.namprd07.prod.outlook.com>
 <CAF+90c-OC8MC9U9GUkctizWVDPnVjuA6nibWgnV8c1Whyw+wLw@mail.gmail.com>
 <CANS-=pdjm2CraKmX-p-6OP1gpdnnTzSx6m2BggddDk5O4Hh89w@mail.gmail.com> <DM6PR07MB6618241A1FEA3234C4E38A7EF92E0@DM6PR07MB6618.namprd07.prod.outlook.com>
In-Reply-To: <DM6PR07MB6618241A1FEA3234C4E38A7EF92E0@DM6PR07MB6618.namprd07.prod.outlook.com>
Date: Thu, 3 Sep 2020 14:18:01 +0200
Message-ID: <CAF+90c_V6AYLR3igJWqV-BLXmHeL+ZTuCzXCxHP1-sQ4f+me+g@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: Lynn <kjarli@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000044f0f505ae67bf0b"
Subject: Re: [PHP-DEV] [RFC] Global functions any() and all() on iterables
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000044f0f505ae67bf0b
Content-Type: text/plain; charset="UTF-8"

On Wed, Sep 2, 2020 at 1:54 AM tyson andre <tysonandre775@hotmail.com>
wrote:

> Hi Lynn and Nikita,
>
> > To be in line with naming conventions, I would suggest calling these
> > iter_any() and iter_all(), using iter_* as the prefix for our future
> > additions to the "functions that work on arbitrary iterables" space.
> > iterable_any() and iterable_all() would work as well, though are
> > unnecessarily verbose.
>
> I'd also feel like iter_any() could get confused with iterator_apply() for
> Traversable
> in terms of whether it's shorthand for iterator or iterable when learning
> the language.
>
> There's been more discussion than I expected on this, arguments for both
> options, and I'm not sure what the overall sentiment of voters is.
> I was considering creating a straw poll on the wiki with 2 questions to
> guide the final version of the RFC/PR:
>
> 1. Name choice (iterator_all(), iter_all(), or all(), or no interest in
> adding the functionality)
> 2. Interest in future RFCs to extend support to keys and entries
>
> Thanks,
> - Tyson


The main thing I'm concerned about is that once we start extending this
area (I assume that any & all are not going to be the last additions in
this space) we will quickly run into function names that are either too
generic or outright collide. For example, what if we want to add an
iterator-based version of range()? Do we *really* want to be forced to pull
a Python and call it xrange()? That's about as good as real_range()...

As such, I think it's important to prefix these *somehow*, though I don't
care strongly how. Could be iter_all() or iterable_all(). We might even
make it iterator_all() if we also adjust other existing iterator_*
functions to accept iterables. I'd also be happy with iter\all() or
iterable\all(), but that gets us back into namespacing discussions :)

Regards,
Nikita

--00000000000044f0f505ae67bf0b--