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

Mark Randall

5 years ago

On 19/12/2020 20:24, tyson andre wrote:

> 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(...);

Sara Golemon

5 years ago

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')) {

}

tyson andre

5 years ago

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

Pierre

5 years ago

Le 22/12/2020 à 01:48, tyson andre a écrit :

> 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

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

tyson andre

5 years ago

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

Larry Garfield

5 years ago

On Tue, Dec 22, 2020, at 9:27 AM, tyson andre wrote:

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

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

Pierre

5 years ago

Le 22/12/2020 à 16:27, tyson andre a écrit :

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

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

Marco Pivetta

5 years ago

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 🤷‍♀️

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

[ ]

5 years ago

Fully agree with Marco

On Tue, Dec 22, 2020, 1:00 PM Marco Pivetta <ocramius@gmail.com> wrote:

tyson andre

5 years ago

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

Girgias

5 years ago

On Tue, 22 Dec 2020 at 16:05, tyson andre <tysonandre775@hotmail.com> wrote:

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

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

Unnamed Person

5 years ago

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

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

Craig Duncan (PHP)

5 years ago

On Tue, 22 Dec 2020 at 16:21, Larry Garfield <larry@garfieldtech.com> wrote:

> 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

tyson andre

5 years ago

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

Niklas Keller

5 years ago

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

Unnamed Person

5 years ago

On Sat, Dec 26, 2020 at 10:02 AM Niklas Keller <me@kelunik.com> 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, 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.

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.

tyson andre

5 years ago

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

Nikita Popov

5 years ago

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

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

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

Unnamed Person

5 years ago

On Wed, Jan 6, 2021 at 1:55 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

>
> On Wed, Jan 6, 2021 at 2:28 AM tyson andre <tysonandre775@hotmail.com>
> wrote:
>
> > 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)
> >
>
> 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.

Unnamed Person

5 years ago

On Wed, Jan 6, 2021 at 7:39 AM Levi Morrison
<levi.morrison@datadoghq.com> wrote:

>
> On Wed, Jan 6, 2021 at 1:55 AM Nikita Popov <nikita.ppv@gmail.com> wrote:
> >
> > On Wed, Jan 6, 2021 at 2:28 AM tyson andre <tysonandre775@hotmail.com>
> > wrote:
> >
> > > 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)
> > >
> >
> > 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.

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.

Nikita Popov

5 years ago

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

> On Wed, Jan 6, 2021 at 1:55 AM Nikita Popov <nikita.ppv@gmail.com> wrote:
> >
> > On Wed, Jan 6, 2021 at 2:28 AM tyson andre <tysonandre775@hotmail.com>
> > wrote:
> >
> > > 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)
> > >
> >
> > 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.
>

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

Mark Randall

5 years ago

On 06/01/2021 14:57, Nikita Popov wrote:

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

tyson andre

5 years ago

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)

> From Nikita Popov,
> 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.

I'm planning to revise https://wiki.php.net/rfc/any_all_on_iterable_straw_poll_namespace
due to feedback that the proposed namespace choices differs from prior proposals 
such as https://wiki.php.net/rfc/php_namespace_policy and perceived interest in options such as PHP\SubNS\

Although my original intent was to add `*any*()` and `*all*()` to the language
rather than work on PHP namespace policy,
I still feel obligated to gather feedback for this specific use case
since this discussion may come up in future RFCs adding new categories of functionality.

There'd be an unmanageable amount of options to vote among if I poll on the combination of namespace and name,
which is even more unpleasant since we currently don't have a widget dedicated to STV(Single Transferrable Vote) polls (that I know of),
just forms that must be submitted individually.
(e.g. is X\iter\any_value() preferable over X\iterable_any())

- Additionally, we haven't yet determined if there's a consensus on namespaces.

My plan is to start a different STV straw poll, on

- no namespace: iterable_any()/iterable_all()
- iter\ (conflicts with nikic/iter but was also suggested by Nikita)
- iterable\ (see below note)
- PHP\ (This deliberately uses uppercase, see https://www.php.net/manual/en/language.namespaces.rationale.php)
- PHP\iter\
- PHP\iterable\ (see below note)
- Ext\Spl\, as suggested in https://wiki.php.net/rfc/php_namespace_policy
- Spl\
- Spl\iter\
- Spl\iterable\ (see below note)

And if there's a clear preference for a namespace, start a second STV straw poll between iterable_any(), NS\any(), NS\any_value, NS\iterable_any(), for the preferred namespace.

I've also realized that `use prefix\iterable` would be mildly inconvenient for users of PHP and for tooling for PHP,
but still include it as an option because it's manageable and the non-namespaced prefix `iterable_` was preferred in the previous poll.

```
php > namespace W { echo iterable::class; }
W\iterable

php > namespace X { use iterable; }

Fatal error: Cannot use iterable as iterable because 'iterable' is a special class name in php shell code on line 1
php > namespace X { use iterable\any; /* using individual functions works */ }
php > namespace Y { use PHP\iterable; function foo(iterable $x) {}}

Fatal error: Cannot use PHP\iterable as iterable because 'iterable' is a special class name in php shell code on line 1
php > namespace Z { use PHP\iterable as iter; }
php > namespace iterable { echo "can be polyfilled\n"; }
can be polyfilled
```

- I don't personally see the need for having "Cannot use iterable as iterable" be a fatal error (especially since that token can be used in namespaces), 
  but I'd really prefer avoiding iterable entirely to avoid special case namespaces in PHP's standard library.

  It could be argued that the type is in some sense used by any namespace so it's permissible to silently allow it.
  `namespace W { echo iterable::class; }` is `W\iterable`, so this isn't technically true.

  It'd also be inconsistent to allow `use iterable;` but not `use int;`, but making that change is a separate proposal.
- `use PHP\iterable` would cause some inconvenience, but code can work around it with `use PHP\iterable as iter;`.
  This may cause edge cases in IDEs, automatically generated code changes, etc.
- The edge cases involved in `iterable` are why I propose iter\ as an additional voting option. 

Thanks,
- Tyson

Unnamed Person

5 years ago

I want to make a case for `Spl`. Aside from autoloading (which really
ought to be in core but since "spl" is literally in the name of those
functions it's kind of stuck), the SPL is mostly data structures and
iterator related functionality. It makes perfect sense to me that
iterator related behavior like these iterable functions being proposed
should be included in the SPL. The `Spl` namespace is short, and its
brevity doesn't lose any meaning because the SPL has been around in
core since PHP 5.3 (I think?).

I do think we need to propose at least a few more things at the same
time to help set the correct patterns and precedent. I'm leaving off
the namespace here:

Variants on what is already proposed:
- any_value(iterable $of, callable $satisfies)
- all_values(iterable $of, callable $satisfy)

These are iterable primitives to implement many other routines:
- reduce_values(iterable $of, callable $by) // throws if there isn't
at least 1 value
- fold_values(iterable $of, $withInitial, callable $by) // like reduce
but doesn't throw since it can use an initial
- to_iterator(iterable): Iterator // to be able to write the previous
two functions in a generic way

New iterators (I have a patch for the first one:
https://github.com/morrisonlevi/php-src/tree/spl/ForwardArrayIterator)
- ForwardArrayIterator // to have an efficient iterator for Array
(ArrayIterator nearly always duplicates the array)
- ReverseArrayIterator // long overdue

Less certain on these specific names but this functionality is common:
- values(iterable $of): iterable // only returns values (does not
fetch keys at all)
- keys(iterable $of): iterable // returns the keys as values (does not
fetch values at all)

Some common ones like map and filter have a bit more nuance because

-----

One of the arguments against using the SPL is that much of its
existing design is... well, weird and sub-optimal in many cases. At
least a few people recommend against using SPL data structures and
iterators because of this. However, I think the `Spl` namespace can
separate these well enough.

Mark Randall

5 years ago

On 10/01/2021 16:52, tyson andre wrote:

> - no namespace: iterable_any()/iterable_all()
> - iter\ (conflicts with nikic/iter but was also suggested by Nikita)
> - iterable\ (see below note)
> - PHP\ (This deliberately uses uppercase, see https://www.php.net/manual/en/language.namespaces.rationale.php)
> - PHP\iter\
> - PHP\iterable\ (see below note)
> - Ext\Spl\, as suggested in https://wiki.php.net/rfc/php_namespace_policy
> - Spl\
> - Spl\iter\
> - Spl\iterable\ (see below note)

FWIW as iterables and the likes relate to engine features, the PHP
namespace policy RFC would have considered them ideal candidates for
\PHP\SubNS rather than \Ext\SubNS

Mark Randall

tyson andre

5 years ago

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)
> 
> > From Nikita Popov,
> > 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.
> 
> I'm planning to revise https://wiki.php.net/rfc/any_all_on_iterable_straw_poll_namespace
> due to feedback that the proposed namespace choices differs from prior proposals 
> such as https://wiki.php.net/rfc/php_namespace_policy and perceived interest in options such as PHP\SubNS\
> 
> Although my original intent was to add `*any*()` and `*all*()` to the language
> rather than work on PHP namespace policy,
> I still feel obligated to gather feedback for this specific use case
> since this discussion may come up in future RFCs adding new categories of functionality.
> 
> There'd be an unmanageable amount of options to vote among if I poll on the combination of namespace and name,
> which is even more unpleasant since we currently don't have a widget dedicated to STV(Single Transferrable Vote) polls (that I know of),
> just forms that must be submitted individually.
> (e.g. is X\iter\any_value() preferable over X\iterable_any())
> 
> - Additionally, we haven't yet determined if there's a consensus on namespaces.
> 
> My plan is to start a different STV straw poll, on
> 
> - no namespace: iterable_any()/iterable_all()
> - iter\ (conflicts with nikic/iter but was also suggested by Nikita)
> - iterable\ (see below note)
> - PHP\ (This deliberately uses uppercase, see https://www.php.net/manual/en/language.namespaces.rationale.php)
> - PHP\iter\
> - PHP\iterable\ (see below note)
> - Ext\Spl\, as suggested in https://wiki.php.net/rfc/php_namespace_policy
> - Spl\
> - Spl\iter\
> - Spl\iterable\ (see below note)
> 
> And if there's a clear preference for a namespace, start a second STV straw poll between iterable_any(), NS\any(), NS\any_value, NS\iterable_any(), for the preferred namespace.

I've updated https://wiki.php.net/rfc/any_all_on_iterable_straw_poll_namespace to be a vote on the namespace choice rather than only Spl\ options.
I plan to start voting on that straw poll in a few days, with the vote left open for 2 weeks.

If there's a clear preference for a namespace, I plan to start a second STV straw poll between iterable_any(), NS\any(), NS\any_value, and NS\iterable_any() (if appropriate), for the preferred namespace.

Thanks,
- Tyson