# Straw poll: Naming for `*any()` and `*all()` on iterables

- Thread: https://externals.io/message/112558
- Original archive: https://news-web.php.net/php.internals/112558
- Started by tyson andre on 2020-12-19T20:24:01+00:00
- Messages: 29
- RFC: PHP\iterable\any() and all() on iterables (Declined) — https://externals.io/rfc/any_all_on_iterable.md
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/112558.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #112558 — tyson andre — 2020-12-19T20:24:01+00:00

URL: https://externals.io/message/112558#112558

Hi internals,

I've created a straw poll for the naming pattern to use for `*any()` and `*all()` on iterables.
https://wiki.php.net/rfc/any_all_on_iterable_straw_poll

Background: The RFC https://wiki.php.net/rfc/any_all_on_iterable proposes adding only two functions,
but more functionality acting on iterables (array|Traversable) may be added in the future,
making it important to get feedback what people feel the best choice of naming pattern would be
to avoid inconsistency or name changes later on.
(Many alternatives were suggested in the initial RFC announcement - https://externals.io/message/111756)

Thanks,
- Tyson

---

## #112569 — Mark Randall — 2020-12-20T23:10:09+00:00

URL: https://externals.io/message/112558#112569 · In reply to: #112558

> Hi internals,
> 
> I've created a straw poll for the naming pattern to use for `*any()` and `*all()` on iterables.
> https://wiki.php.net/rfc/any_all_on_iterable_straw_poll

These functions make sense. However I think we need to give renewed 
consideration to:

$itr->all();
$itr->some(...);

---

## #112570 — tyson andre — 2020-12-20T23:56:29+00:00

URL: https://externals.io/message/112558#112570

Hi Mark Randall,

> These functions make sense. However I think we need to give renewed 
> consideration to:
> 
> $itr->all();
> $itr->some(...);

That wouldn't help for arrays, which would be the most common use case - I don't remember seeing an RFC for https://github.com/nikic/scalar_objects and that is a much larger language change.

This also wouldn't help if I wanted something that could be used on any Traversable.
Currently, there's no support for default methods for interfaces such as Iterator/IteratorAggregate - I think I saw some discussion of that.
(e.g. to check for any()/all() on generators, user-defined classes, etc)
Backwards compatibility of method signatures with the same names that were written before default methods were added would be a concern, though.
(https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html)

Regards,
- Tyson

---

## #112574 — Larry Garfield — 2020-12-21T15:56:48+00:00

URL: https://externals.io/message/112558#112574 · In reply to: #112570

> Hi Mark Randall,
> 
> > […]
> 
> That wouldn't help for arrays, which would be the most common use case 
> - I don't remember seeing an RFC for 
> https://github.com/nikic/scalar_objects and that is a much larger 
> language change.
> 
> This also wouldn't help if I wanted something that could be used on any 
> Traversable.
> Currently, there's no support for default methods for interfaces such 
> as Iterator/IteratorAggregate - I think I saw some discussion of that.
> (e.g. to check for any()/all() on generators, user-defined classes, etc)
> Backwards compatibility of method signatures with the same names that 
> were written before default methods were added would be a concern, 
> though.
> (https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html)

Related: I am planning to get back to the pipe operator at some point during the 8.1 cycle; right now the only blocker is finishing the partial function application RFC (which is partially completed, no pun intended, but currently lagging due to lack of time; Ilija was working on it but is focused on enums at the moment).  Assuming pipe passes (since the feedback was quite positive last time with the caveat of wanting partials first), that would open up the potential for functions that return iterator-expecting functions to be used in pipes.  To wit:

function i_map(callable $fn): callable {
  return function (iterable $list) use ($fn) {
    foreach ($list as $k => $v) {
      yield $fn($v, $k);
    }
  }
}

$any_iterable |> i_map($some_callable) |> i_filter($other_callable) |> any($boolean_check);

That would obviate the need to have proper methods on iterables as the combination of |> and higher order functions gives a similarly chainable syntax without the need to think about what objects have what methods on them at compile time.

It's not perfect, but I think it's a good solution to a long-standing challenge.  (Whether or not such higher order functions belong in the standard lib is debatable; it probably depends on what the performance difference is.)

--Larry Garfield

---

## #112575 — Sara Golemon — 2020-12-21T17:39:39+00:00

URL: https://externals.io/message/112558#112575 · In reply to: #112558

On Sat, Dec 19, 2020 at 2:24 PM tyson andre <tysonandre775@hotmail.com>
wrote:

> I've created a straw poll for the naming pattern to use for `*any()` and
> `*all()` on iterables.
> https://wiki.php.net/rfc/any_all_on_iterable_straw_poll
>
>
This is probably going to be a terrible idea because it involves a little
magic but...

"iterable" is already a forbidden userspace class name since it's reserved
for the psuedo-type which is a union of `Traversable | array`.

What if we went ahead and defined an actual (abstract-final) `iterable`
class.  The parser rules which treat `iterable` as a special type still
apply, so we never try to match instances of class `iterable`, but what we
can do is define methods on it.

class Iterable {
    static public function any(iterable $iter, Callable $predicate): bool {
... }
    static public function all(iterable $iter, Callable $predicate): bool {
... }
}

Then the API is both 100% searchable (the man page for iterable can explain
that it's a pseudo-type AND that it has helper methods), and intuitive to
read/write.

if (iterable::any($iter, fn($elem) => $elem === 'foo')) {

}

---

## #112583 — tyson andre — 2020-12-22T00:48:01+00:00

URL: https://externals.io/message/112558#112583 · In reply to: #112575

Hi Sara Golemon,

> This is probably going to be a terrible idea because it involves a little magic but...
>
> "iterable" is already a forbidden userspace class name since it's reserved for the psuedo-type which is a union of `Traversable | array`.
>
> What if we went ahead and defined an actual (abstract-final) `iterable` class.  The parser rules which treat `iterable` as a special type still apply, so we never try to match instances of class `iterable`, but what we can do is define methods on it.
>
> class Iterable {
>    static public function any(iterable $iter, Callable $predicate): bool { ... }
>    static public function all(iterable $iter, Callable $predicate): bool { ... }
> }
>
> Then the API is both 100% searchable (the man page for iterable can explain that it's a pseudo-type AND that it has helper methods), and intuitive to read/write.
>
> if (iterable::any($iter, fn($elem) => $elem === 'foo')) {
>
> }

My objections to that are:

1. As mentioned in https://wiki.php.net/rfc/any_all_on_iterable_straw_poll#rejected_choices , I'd objected to static methods in general because it would be inconvenient to polyfill
    (magic such as __callStatic or disable_classes might be possible but inconvenient and integrate poorly with IDEs/analyzers)

    (if more than 2/3rs of php developers are in favor of more comprehensive functionality later on, such as none(), first(), etc.)
2. The name `iterable::any` would make it impossible to polyfill iterable::any()/all() in php 8.0 without using PECLS that modify the internals of php in unsafe ways (class_alias also forbids 'iterable' as an alias). I'd still prefer IterUtils/IterableUtils:: over iterable::.
3. For these reasons, I assume static methods have been fairly unpopular on functionality not associated with an object instance, but the main reason may be something else.

Also, on an off-topic note, `abstract final` is forbidden for userland classes, so making it have those flags would be surprising for uses of Reflection such as code stub generators,
but forbidding the constructor would be close enough.
Although I think `abstract final` should be allowed like it is in java,
I think RFCs that proposed allowing `abstract final` failed by a large margin years ago and I don't plan to reopen that.

Thanks,
- Tyson

---

## #112587 — Pierre — 2020-12-22T07:37:37+00:00

URL: https://externals.io/message/112558#112587 · In reply to: #112583

Le 22/12/2020 à 01:48, tyson andre a écrit :
> Hi Sara Golemon,
>
> > […]
> My objections to that are:
>
> 1. As mentioned in https://wiki.php.net/rfc/any_all_on_iterable_straw_poll#rejected_choices , I'd objected to static methods in general because it would be inconvenient to polyfill
>      (magic such as __callStatic or disable_classes might be possible but inconvenient and integrate poorly with IDEs/analyzers)
>
>      (if more than 2/3rs of php developers are in favor of more comprehensive functionality later on, such as none(), first(), etc.)
> 2. The name `iterable::any` would make it impossible to polyfill iterable::any()/all() in php 8.0 without using PECLS that modify the internals of php in unsafe ways (class_alias also forbids 'iterable' as an alias). I'd still prefer IterUtils/IterableUtils:: over iterable::.
> 3. For these reasons, I assume static methods have been fairly unpopular on functionality not associated with an object instance, but the main reason may be something else.
>
> Also, on an off-topic note, `abstract final` is forbidden for userland classes, so making it have those flags would be surprising for uses of Reflection such as code stub generators,
> but forbidding the constructor would be close enough.
> Although I think `abstract final` should be allowed like it is in java,
> I think RFCs that proposed allowing `abstract final` failed by a large margin years ago and I don't plan to reopen that.
>
> Thanks,
> - Tyson

Hello,

This is the kind of reasoning I fully support usually, I do maintain a 
few libraries for multiple PHP versions as most people in this list and 
make things easily polifyllable is something I'm sensible to.

Nevertheless, the language and its standard library has to evolve at 
some point. For enumerable objects PHP terribly lacks a complete and 
convenient API for developers. By putting those methods in the global 
namespace, you make those methods usage much less fluent for many 
developers that uses a decent IDE. It'd be a great thing to have a 
compete OO-based (interface based) API for collection methods. any() and 
all() methods are only the start, in my opinion, of much greater 
improvements in that regard, and I'd very much love to have those 
autocompleted by IDE on pretty much everything that is iterable.

That's just an opinion, I'd love to see it evolve towards an 
object-oriented API.

Regards,

Pierre

---

## #112588 — Marco Pivetta — 2020-12-22T11:00:24+00:00

URL: https://externals.io/message/112558#112588 · In reply to: #112558

Hey Tyson,

I know I'm being stubborn, but we have namespaces, but also an "old guard"
that doesn't understand its own programming language 🤷‍♀️



> Hi internals,
>
> I've created a straw poll for the naming pattern to use for `*any()` and
> `*all()` on iterables.
> https://wiki.php.net/rfc/any_all_on_iterable_straw_poll
>
> Background: The RFC https://wiki.php.net/rfc/any_all_on_iterable proposes
> adding only two functions,
> but more functionality acting on iterables (array|Traversable) may be
> added in the future,
> making it important to get feedback what people feel the best choice of
> naming pattern would be
> to avoid inconsistency or name changes later on.
> (Many alternatives were suggested in the initial RFC announcement -
> https://externals.io/message/111756)
>
> Thanks,
> - Tyson
> --
> 
> To unsubscribe, visit: https://www.php.net/unsub.php

---

## #112589 — Eugene Sidelnyk — 2020-12-22T11:18:01+00:00

URL: https://externals.io/message/112558#112589 · In reply to: #112588

Fully agree with Marco



> Hey Tyson,
>
> I know I'm being stubborn, but we have namespaces, but also an "old guard"
> that doesn't understand its own programming language 🤷‍♀️
>
> 
>
> > […]
> proposes
> > […]

---

## #112591 — tyson andre — 2020-12-22T15:05:25+00:00

URL: https://externals.io/message/112558#112591 · In reply to: #112588

Hi Marco,

>Hey Tyson, 
> 
> I know I'm being stubborn, but we have namespaces, but also an "old guard" that doesn't understand its own programming language 🤷‍♀️

I assume it's a case of not liking them or assuming others wouldn't like them instead of not understanding them.
Namespaces for https://www.php-fig.org/psr/psr-4/ has been standard for a long, long time.

And attempts to standardize on adopting them have been unpopular - https://wiki.php.net/rfc/php_namespace_policy
Existing internal functionality for working with iterators and arrays is in the global namespace.

- E.g. it would be slightly more inconvenient to need to write `print(\PHP\get_debug_type($var))` or `use function PHP\get_debug_type; ...; get_debug_type($var);`
  and some developers wouldn't like seeing the extra imports or fully qualified names mixed with code that doesn't use namespaces.
- It's inconsistent for some new categories of functionality to have namespaces when others wouldn't - the php namespace policy vote seems to indicate there's no consensus on what naming pattern we'd have for namespaces.

Even in brand new categories of functionality such as FFI or PhpToken, we've went with the global namespace.

Regards,
- Tyson

---

## #112593 — G. P. B. — 2020-12-22T15:18:07+00:00

URL: https://externals.io/message/112558#112593 · In reply to: #112591

> Hi Marco,
>
> > […]
> guard" that doesn't understand its own programming language 🤷‍♀️
>
> I assume it's a case of not liking them or assuming others wouldn't like
> them instead of not understanding them.
> Namespaces for https://www.php-fig.org/psr/psr-4/ has been standard for a
> long, long time.
>
> And attempts to standardize on adopting them have been unpopular -
> https://wiki.php.net/rfc/php_namespace_policy
> Existing internal functionality for working with iterators and arrays is
> in the global namespace.
>
> - E.g. it would be slightly more inconvenient to need to write
> `print(\PHP\get_debug_type($var))` or `use function PHP\get_debug_type;
> ...; get_debug_type($var);`
>   and some developers wouldn't like seeing the extra imports or fully
> qualified names mixed with code that doesn't use namespaces.
> - It's inconsistent for some new categories of functionality to have
> namespaces when others wouldn't - the php namespace policy vote seems to
> indicate there's no consensus on what naming pattern we'd have for
> namespaces.
>
> Even in brand new categories of functionality such as FFI or PhpToken,
> we've went with the global namespace.
>

Small nitpick but FFI classes are under the FFI\ namespace, e.g. FFI\CData
[1]

George P. Banyard

[1] https://www.php.net/manual/en/class.ffi-cdata.php


>
> Regards,
> - Tyson

---

## #112594 — tyson andre — 2020-12-22T15:27:30+00:00

URL: https://externals.io/message/112558#112594 · In reply to: #112587

Hi Pierre,

> This is the kind of reasoning I fully support usually, I do maintain a 
> few libraries for multiple PHP versions as most people in this list and 
> make things easily polifyllable is something I'm sensible to.
> 
> Nevertheless, the language and its standard library has to evolve at 
> some point. For enumerable objects PHP terribly lacks a complete and 
> convenient API for developers. By putting those methods in the global 
> namespace, you make those methods usage much less fluent for many 
> developers that uses a decent IDE. It'd be a great thing to have a 
> compete OO-based (interface based) API for collection methods. any() and 
> all() methods are only the start, in my opinion, of much greater 
> improvements in that regard, and I'd very much love to have those 
> autocompleted by IDE on pretty much everything that is iterable.
> 
> That's just an opinion, I'd love to see it evolve towards an 
> object-oriented API.

1. If you're talking about adding default methods to Traversables,
   default method implementations would be a major RFC of their own
   for implementation and discussions on guidelines for using them internally.

   It may raise questions such as "why still have both traits and interfaces".

   Some may object to adding too many default methods to the completions for an IDE
   or naming conflicts in projects.
2. I'd find it useful to add, though there may be considerable discussion over what belongs 
   in an API for collection methods, whether they make sense with SplObjectStorage, etc.
3. The pipe operator RFC may be a bit more fluent if a revised version is accepted - https://externals.io/message/112558#112574

   `$exists = create_collection() |> user_defined_filter($$) |> someprefix_any($$)` (possibly different syntax)

4. I'd still want to add this functionality for arrays. Limiting any/all to arrays only would be artificial,
   and projects can use both if `->any()` was added by a different RFC 
   (both `count()`/Countable->count() syntaxes are used in php code)
   

Thanks,
-Tyson

---

## #112596 — Larry Garfield — 2020-12-22T16:20:40+00:00

URL: https://externals.io/message/112558#112596 · In reply to: #112594

> Hi Pierre,
> 
> > […]
> 
> 1. If you're talking about adding default methods to Traversables,
>    default method implementations would be a major RFC of their own
>    for implementation and discussions on guidelines for using them internally.
> 
>    It may raise questions such as "why still have both traits and interfaces".
> 
>    Some may object to adding too many default methods to the 
> completions for an IDE
>    or naming conflicts in projects.
> 2. I'd find it useful to add, though there may be considerable 
> discussion over what belongs 
>    in an API for collection methods, whether they make sense with 
> SplObjectStorage, etc.
> 3. The pipe operator RFC may be a bit more fluent if a revised version 
> is accepted - https://externals.io/message/112558#112574
> 
>    `$exists = create_collection() |> user_defined_filter($$) |> 
> someprefix_any($$)` (possibly different syntax)
> 
> 4. I'd still want to add this functionality for arrays. Limiting 
> any/all to arrays only would be artificial,
>    and projects can use both if `->any()` was added by a different RFC 
>    (both `count()`/Countable->count() syntaxes are used in php code)

For those answering in the straw poll, note that the longer the prefix, the uglier chained calls will get.  Whether that's done with pipe or something else, expect to be typing that prefix a lot.  That's why I am OK with most options except `iterable_`, because that's a lot of needless typing.

--Larry Garfield

---

## #112597 — Pierre — 2020-12-22T16:46:56+00:00

URL: https://externals.io/message/112558#112597 · In reply to: #112594

Le 22/12/2020 à 16:27, tyson andre a écrit :
> Hi Pierre,
>
> > […]

Hello again,

First things first, I'm sorry for answering to all instead of answering 
to the list.

The rest below.

> 1. If you're talking about adding default methods to Traversables,
>     default method implementations would be a major RFC of their own
>     for implementation and discussions on guidelines for using them internally.
Adding default methods to interface would be something I'd love, and 
yes, collection methods could be implemented this way, yet I agree with 
you this would need two RFC, one for default methods, the other for a 
collection API. Doesn't sound impossible to me, just very hard to have 
something people will all agree on to :)
>     It may raise questions such as "why still have both traits and interfaces".
>
>     Some may object to adding too many default methods to the completions for an IDE
>     or naming conflicts in projects.
Sure, every addition poses that risk. I think there's no easy way to go 
around that. But in the other side, it'll probably conflict with 
libraries implementing the same thing, thus obsoleting those. They could 
actually be polyfilled as well and use core's methods behind the scenes.
> 2. I'd find it useful to add, though there may be considerable discussion over what belongs
>     in an API for collection methods, whether they make sense with SplObjectStorage, etc.
I think I would start without thinking about where they belong, by 
writing clean new interfaces first, then see how it comes when applying 
them to existing types one by one.
> 3. The pipe operator RFC may be a bit more fluent if a revised version is accepted - https://externals.io/message/112558#112574
It's fluent in reading, but it's not really in writing code, since when 
I'll type ctrl+space to have autocompletion, it'll autocomplete on the 
global standard library namespace and I'll have thousands of possible 
functions to call.
>     `$exists = create_collection() |> user_defined_filter($$) |> someprefix_any($$)` (possibly different syntax)
>
> 4. I'd still want to add this functionality for arrays. Limiting any/all to arrays only would be artificial,
>     and projects can use both if `->any()` was added by a different RFC
>     (both `count()`/Countable->count() syntaxes are used in php code)

I always thought that arrays should probably be promoted to objects 
somehow, it would make sense. Having array being iterable but not 
traversable always looked very weird to me. And I'd love to call 
$myArray->first(), $myArray->keys(), $myArray->any() etc... as well as 
for any collection, if collections as objects/interface did exist !

Regards,

--

Pierre

---

## #112598 — Levi Morrison via internals — 2020-12-22T17:08:25+00:00

URL: https://externals.io/message/112558#112598 · In reply to: #112558

>
> Hi internals,
>
> I've created a straw poll for the naming pattern to use for `*any()` and `*all()` on iterables.
> https://wiki.php.net/rfc/any_all_on_iterable_straw_poll
>
> Background: The RFC https://wiki.php.net/rfc/any_all_on_iterable proposes adding only two functions,
> but more functionality acting on iterables (array|Traversable) may be added in the future,
> making it important to get feedback what people feel the best choice of naming pattern would be
> to avoid inconsistency or name changes later on.
> (Many alternatives were suggested in the initial RFC announcement - https://externals.io/message/111756)

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.

---

## #112599 — Craig Duncan — 2020-12-22T18:20:13+00:00

URL: https://externals.io/message/112558#112599 · In reply to: #112598

> That's why I am OK with most options except `iterable_`, because that's a
> lot of needless typing.
>

Whether the prefix is iterable or iter or just i, I'll always be typing
iany and hitting enter, letting my IDE do the leg work, avoiding any
needless typing

On Tue, 22 Dec 2020 at 17:08, Levi Morrison via internals <
internals@lists.php.net> wrote:

> 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
>

I don't understand why iter\any() and iter\all() don't appear in this straw
poll as they were in Nikita's original mail

---

## #112600 — tyson andre — 2020-12-22T18:34:23+00:00

URL: https://externals.io/message/112558#112600 · In reply to: #112598

Hi Levi,

> 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.

I can understand the argument that somewhat of a new category of functionality making it a candidate for a new namespace,
but it's common enough for me to want it in the global namespace
(any of the language examples in https://wiki.php.net/rfc/any_all_on_iterable#introduction
have it in an object method, or in a close equivalent to a namespace imported by default such as std::)

My goal is to add two functions, not the much, much larger goal of setting a precedent for the many topics which adopting namespaces would provide
(choice of prefix, choice of casing, choice of `SPL\`, `EXT\SPL\`, `PHP\`, `PHP\iterable\`, or `Spl\`, or `iterable\`, whether the extra verbosity is worth the benefit, etc.),
which may be more contentious than the decision to not start using namespaces here.
Both https://wiki.php.net/rfc/php-namespace-in-core and https://wiki.php.net/rfc/php_namespace_policy have been opposed,
and I anticipate disagreement on any of those from https://externals.io/message/110711

Adopting namespaces without having any form of consensus on the way namespaces
would be set up seems like it would be a potential source of language inconsistency and making it harder to learn,
if some core functions are `PHP\strings\tolower_c_locale()`, some are `iterable\something(), others are `Ext\Graphics\draw_line()`, etc.

Thanks,
- Tyson

---

## #112621 — Niklas Keller — 2020-12-26T16:59:58+00:00

URL: https://externals.io/message/112558#112621 · In reply to: #112598

>
> 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

---

## #112752 — Levi Morrison via internals — 2021-01-04T17:27:43+00:00

URL: https://externals.io/message/112558#112752 · In reply to: #112621

> > […]
>
>
> 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.

I agree they are a bit generic, especially because we may need to
distinguish between keys and values. For that reason I prefer
`Spl\all_values` and `Spl\any_value`. We can make it read very well
with named parameters if that's your thing:

```
if (all_values($input, 'is_int'))
// or alternatively:
if (all_values(of: $input, satisfy: 'is_int'))
```

I wouldn't put too much excitement into making highly readable
English; I mention it mostly to point out that I think we should put
at least a little bit of effort into parameter names for any new
library additions.

> 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?

Many of them can't work efficiently on iterables or have
idiosyncrasies. I don't think this the way forward either.

-----

I am hopeful we can add at least a few other functions alongside these
additions to help establish good patterns for functions that work with
iterables, as there are quite a few of them. At least we should add
some form of `reduce`, as `any` and `all` are forms of reducers.

---

## #112771 — tyson andre — 2021-01-06T01:27:56+00:00

URL: https://externals.io/message/112558#112771 · In reply to: #112558

Hi internals,

> I've created a straw poll for the naming pattern to use for `*any()` and `*all()` on iterables.
> https://wiki.php.net/rfc/any_all_on_iterable_straw_poll
> 
> Background: The RFC https://wiki.php.net/rfc/any_all_on_iterable proposes adding only two functions,
> but more functionality acting on iterables (array|Traversable) may be added in the future,
> making it important to get feedback what people feel the best choice of naming pattern would be
> to avoid inconsistency or name changes later on.
> (Many alternatives were suggested in the initial RFC announcement - https://externals.io/message/111756)

I've received more feedback than I expected from voters that were strongly or moderately
in favor of putting new categories of functionality in namespaces.

I've started a different straw poll and plan to start voting on that on the 8th (this will be the last straw poll for iterable function naming for this RFC)
https://wiki.php.net/rfc/any_all_on_iterable_straw_poll_namespace

1. I plan to propose additional internal functions for working with iterables if this succeeds,
   and would want to be sure this is the best name choice instead of just an acceptable name choice going forwards.
2. Additionally, this has been an opportunity for measuring overall interest in adopting namespaces for brand new categories of functionality.
   It can be argued that this is a new category of functionality because existing methods work on Traversables (iterator_*) or arrays (array_*), but generally not both.
  (classes such as https://www.php.net/manual/en/class.ffi-cdata.php have adopted namespaces,
  but no global functions in php-src that I'm aware of have adopted namespaces yet)


Thanks,
- Tyson

---

## #112773 — Nikita Popov — 2021-01-06T08:55:07+00:00

URL: https://externals.io/message/112558#112773 · In reply to: #112771

On Wed, Jan 6, 2021 at 2:28 AM tyson andre <tysonandre775@hotmail.com>
wrote:

> Hi internals,
>
> > […]
> `*all()` on iterables.
> > […]
> proposes adding only two functions,
> > […]
> added in the future,
> > […]
> naming pattern would be
> > […]
> https://externals.io/message/111756)
>
> I've received more feedback than I expected from voters that were strongly
> or moderately
> in favor of putting new categories of functionality in namespaces.
>
> I've started a different straw poll and plan to start voting on that on
> the 8th (this will be the last straw poll for iterable function naming for
> this RFC)
> https://wiki.php.net/rfc/any_all_on_iterable_straw_poll_namespace
>
> 1. I plan to propose additional internal functions for working with
> iterables if this succeeds,
>    and would want to be sure this is the best name choice instead of just
> an acceptable name choice going forwards.
> 2. Additionally, this has been an opportunity for measuring overall
> interest in adopting namespaces for brand new categories of functionality.
>    It can be argued that this is a new category of functionality because
> existing methods work on Traversables (iterator_*) or arrays (array_*), but
> generally not both.
>   (classes such as https://www.php.net/manual/en/class.ffi-cdata.php have
> adopted namespaces,
>   but no global functions in php-src that I'm aware of have adopted
> namespaces yet)
>

I'm happy to have these functions namespaced, but I'm not sure the
suggestion to namespace them under Spl makes sense. This functionality has
fairly little to do with the SPL as it is now and to be honest, by now
there is quite a bit of ... stigma associated with functionality that
resides in SPL.

I would suggest using iterable\any and iterable\all as the names if we want
to go down this route. iterable_any and iterable_all were the by far most
popular choices on the previous poll, and these are just the namespaced
variants thereof.

Regards,
Nikita

---

## #112778 — Levi Morrison via internals — 2021-01-06T14:39:49+00:00

URL: https://externals.io/message/112558#112778 · In reply to: #112773

>
> On Wed, Jan 6, 2021 at 2:28 AM tyson andre <tysonandre775@hotmail.com>
> wrote:
>
> > […]
>
> I'm happy to have these functions namespaced, but I'm not sure the
> suggestion to namespace them under Spl makes sense. This functionality has
> fairly little to do with the SPL as it is now and to be honest, by now
> there is quite a bit of ... stigma associated with functionality that
> resides in SPL.
>
> I would suggest using iterable\any and iterable\all as the names if we want
> to go down this route. iterable_any and iterable_all were the by far most
> popular choices on the previous poll, and these are just the namespaced
> variants thereof.
>
> Regards,
> Nikita

On the contrary, I'm happy to accept it into the SPL. I don't want the
SPL to be a dumping ground for everything, but I specifically
requested it to be an option for this vote.

---

## #112779 — Levi Morrison via internals — 2021-01-06T14:50:43+00:00

URL: https://externals.io/message/112558#112779 · In reply to: #112778

On Wed, Jan 6, 2021 at 7:39 AM Levi Morrison
<levi.morrison@datadoghq.com> wrote:
>
> 
> > […]
>
> On the contrary, I'm happy to accept it into the SPL. I don't want the
> SPL to be a dumping ground for everything, but I specifically
> requested it to be an option for this vote.

I forgot to mention that I plan other additions to the SPL for 8.1, such as:

- ForwardArrayIterator
- ReverseArrayIterator
- to_iterator(iterable): Iterator -- this needs ForwardArrayIterator
for efficiency

I plan to stick all of these in the SPL namespace.

---

## #112780 — Nikita Popov — 2021-01-06T14:57:41+00:00

URL: https://externals.io/message/112558#112780 · In reply to: #112778

On Wed, Jan 6, 2021 at 3:40 PM Levi Morrison <levi.morrison@datadoghq.com>
wrote:

> 
> > […]
> and
> > […]
> of
> > […]
> strongly
> > […]
> for
> > […]
> just
> > […]
> functionality.
> > […]
> because
> > […]
> (array_*), but
> > […]
> have
> > […]
> has
> > […]
> want
> > […]
>
> On the contrary, I'm happy to accept it into the SPL. I don't want the
> SPL to be a dumping ground for everything, but I specifically
> requested it to be an option for this vote.
>

Using *just* the SPL namespace (that is, SPL\any) makes the SPL namespace a
dumping ground for everything, as you said. Once you introduce an
additional meaningful namespace in the form of SPL\iterable\any, you are
better off either dropping the SPL part and arriving at iterable\any, or
replacing SPL with something more sensible and arriving at PHP\iterable\any.

TBH I think Tyson's original approach of not including namespaces as a
possibility was the right one. We clearly still don't have any consensus on
how to structure namespaces in PHP extensions and it doesn't seem like a
question that should be resolved as a footnote of another RFC. There have
been multiple RFCs one the topic, and none of them reached anything even
approaching a consensus.

Regards,
Nikita

---

## #112821 — Mark Randall — 2021-01-09T18:24:34+00:00

URL: https://externals.io/message/112558#112821 · In reply to: #112780

> Once you introduce an
> additional meaningful namespace in the form of SPL\iterable\any, you are
> better off either dropping the SPL part and arriving at iterable\any, or
> replacing SPL with something more sensible and arriving at PHP\iterable\any.



PHP\ModuleOrFeature\Abc was the style listed in the PHP Namespace Policy 
RFC presented by Larry and I, which was voted down, perhaps due to 
specific elements of the RFC, or perhaps due to a dislike of namespaces 
in general.

If you believe that PHP\ModuleOrFeature\Abc is a sensible approach to 
take, then I would implore you to pick up the mantle and try and push 
everyone towards agreement, lest this keep coming up again, and again.

Fortunately, your words carry great weight, and you're likely to be one 
of the few people who could succeed where so many others of us have 
tried and failed.

---

Next page: https://externals.io/message/112558.md?page=2