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

4 years ago by Mark Randall — view source — reply

unread

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

4 years ago by Sara Golemon — view source — reply

unread

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

}

4 years ago by tyson andre — view source — reply

unread

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:

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

4 years ago by Pierre — view source — reply

unread

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:

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

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

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

4 years ago by tyson andre — view source — reply

unread

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.

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

4 years ago by Larry Garfield — view source — reply

unread

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.

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.

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.

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)

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

4 years ago by Pierre — view source — reply

unread

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.

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.

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.

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)

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

4 years ago by Marco Pivetta — view source — reply

unread

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

4 years ago by Eugene Sidelnyk — view source — reply

unread

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

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

4 years ago by tyson andre — view source — reply

unread

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

4 years ago by G. P. B. — view source — reply

unread

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

Regards,

Tyson

4 years ago by Levi Morrison via internals — view source — reply

unread

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.

4 years ago by Craig Duncan — view source — reply

unread

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

4 years ago by tyson andre — view source — reply

unread

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

4 years ago by Niklas Keller — view source — reply

unread

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

4 years ago by Levi Morrison via internals — view source — reply

unread

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.

4 years ago by tyson andre — view source — reply

unread

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

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

4 years ago by Nikita Popov — view source — reply

unread

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

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.

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

4 years ago by Levi Morrison via internals — view source — reply

unread

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

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.

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.

4 years ago by Levi Morrison via internals — view source — reply

unread

On Wed, Jan 6, 2021 at 7:39 AM Levi Morrison
levi.morrison@datadoghq.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

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.

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.

4 years ago by Nikita Popov — view source — reply

unread

On Wed, Jan 6, 2021 at 3:40 PM Levi Morrison levi.morrison@datadoghq.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

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.

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

4 years ago by Mark Randall — view source — reply

unread

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.

4 years ago by tyson andre — view source — reply

unread

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

4 years ago by Levi Morrison via internals — view source — reply

unread

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.

4 years ago by Mark Randall — view source — reply

unread

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

4 years ago by tyson andre — view source — reply

unread

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