Re: Straw poll: Naming for `*any()` and `*all()` on iterables
| From: | Niklas Keller | Date: | Sat, 26 Dec 2020 16:59:58 +0000 |
| Subject: | Re: Straw poll: Naming for `*any()` and `*all()` on iterables | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-112621@lists.php.net to get a copy of this message | ||
>
> 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.
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?
Best,
Niklas