Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Make iterator_to_array() accept all iterables »

Make iterator_to_array() accept all iterables

php.internals

Tim Düsterhus

4 years ago
Hi Internals I've come across a case where it would've been useful if `iterator_to_array()` would accept iterable instead of Traversable to avoid checking whether the input variable already is an array. To not repeat what I've already written in my proposed PR, please see: https://github.com/php/php-src/pull/8819 for more details. In response to my question whether this would require an RFC or whether this is simple enough, cmb pointed to a previous RFC that proposed *adding* a new function `iterable_to_array()` which was declined: https://wiki.php.net/rfc/iterable_to_array-and-iterable_count cmb also suggested that for this reason this topic should at least be shortly discussed on the list, which I intend to do with this email: - Do you believe that my PR requires an RFC / do you want to see an RFC for this? - Would you object to extending 'iterator_to_array' from Traversable to iterable (i.e. to Traversable|array)? Best regards Tim Düsterhus

Girgias

4 years ago
On Fri, 17 Jun 2022 at 16:20, Tim Düsterhus <tim@bastelstu.be> wrote:
> Hi Internals > > I've come across a case where it would've been useful if > `iterator_to_array()` would accept iterable instead of Traversable to > avoid checking whether the input variable already is an array. > > To not repeat what I've already written in my proposed PR, please see: > > https://github.com/php/php-src/pull/8819 > > for more details. > > In response to my question whether this would require an RFC or whether > this is simple enough, cmb pointed to a previous RFC that proposed > *adding* a new function `iterable_to_array()` which was declined: > > https://wiki.php.net/rfc/iterable_to_array-and-iterable_count > > cmb also suggested that for this reason this topic should at least be > shortly discussed on the list, which I intend to do with this email: > > - Do you believe that my PR requires an RFC / do you want to see an RFC > for this? > - Would you object to extending 'iterator_to_array' from Traversable to > iterable (i.e. to Traversable|array)? > > Best regards > Tim Düsterhus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php
Considering the other RFC has been declined, and I can see the value of it and the change is rather minimal, if no one has any objections I think this is fine to land without any RFC. Best regards, George P. Banyard

Unnamed Person

4 years ago
On Fri, Jun 17, 2022 at 9:28 AM G. P. B. <george.banyard@gmail.com> wrote:
> > On Fri, 17 Jun 2022 at 16:20, Tim Düsterhus <tim@bastelstu.be> wrote: > > > Hi Internals > > > > I've come across a case where it would've been useful if > > `iterator_to_array()` would accept iterable instead of Traversable to > > avoid checking whether the input variable already is an array. > > > > To not repeat what I've already written in my proposed PR, please see: > > > > https://github.com/php/php-src/pull/8819 > > > > for more details. > > > > In response to my question whether this would require an RFC or whether > > this is simple enough, cmb pointed to a previous RFC that proposed > > *adding* a new function `iterable_to_array()` which was declined: > > > > https://wiki.php.net/rfc/iterable_to_array-and-iterable_count > > > > cmb also suggested that for this reason this topic should at least be > > shortly discussed on the list, which I intend to do with this email: > > > > - Do you believe that my PR requires an RFC / do you want to see an RFC > > for this? > > - Would you object to extending 'iterator_to_array' from Traversable to > > iterable (i.e. to Traversable|array)? > > > > Best regards > > Tim Düsterhus > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > > > Considering the other RFC has been declined, and I can see the value of it > and the change is rather minimal, if no one has any objections I think this > is fine to land without any RFC.
Personally, I take the opposite view. This has already been declined; why should it be able to avoid the RFC process when something so similar was declined recently?

Larry Garfield

4 years ago
On Fri, Jun 17, 2022, at 10:20 AM, Tim Düsterhus wrote:
> Hi Internals > > I've come across a case where it would've been useful if > `iterator_to_array()` would accept iterable instead of Traversable to > avoid checking whether the input variable already is an array. > > To not repeat what I've already written in my proposed PR, please see: > > https://github.com/php/php-src/pull/8819 > > for more details. > > In response to my question whether this would require an RFC or whether > this is simple enough, cmb pointed to a previous RFC that proposed > *adding* a new function `iterable_to_array()` which was declined: > > https://wiki.php.net/rfc/iterable_to_array-and-iterable_count > > cmb also suggested that for this reason this topic should at least be > shortly discussed on the list, which I intend to do with this email: > > - Do you believe that my PR requires an RFC / do you want to see an RFC > for this? > - Would you object to extending 'iterator_to_array' from Traversable to > iterable (i.e. to Traversable|array)?
I support this; my only wrinkle would be that it's still a long name compared to what many languages have for this functionality, but I suppose that ship has long since sailed. :-) Since it's a strictly type-widening change with no BC implications I can think of, I am impartial on RFC or not. If it's going to get an RFC, though, that needs to be posted, like, immediately if it's going to get into 8.2. --Larry Garfield

Guilliam Xavier

4 years ago
> https://github.com/php/php-src/pull/8819
Just so that it can't be said that it hasn't been asked: what about iterator_count(), and iterator_apply()? Regards,
-- Guilliam Xavier

Tim Düsterhus

4 years ago
Hi On 6/17/22 18:06, Guilliam Xavier wrote:
>> https://github.com/php/php-src/pull/8819 > > Just so that it can't be said that it hasn't been asked: what about > iterator_count(), and iterator_apply()?
I also came across those, while implementing the PR, but I intentionally did not touch them to keep the scope simple and because I think they are less likely to be used generally. - `iterator_apply()` is easily replaced by a foreach loop, because the return value is pretty useless, so it is not likely that a nested function call is going to be used. - For `iterator_count()` one could to `count(iterator_to_array($foo))` if my proposal is merged. This come with a bit of overhead, but at least it's not as clunky as `is_array($foo) ? $foo : iterator_to_array($foo)` If a RFC is desired, then I'd likely include all three of them with a vote for each, but I hope my proposal is simple enough to not require an RFC. Best regards Tim Düsterhus

Guilliam Xavier

4 years ago
On Fri, Jun 17, 2022 at 7:21 PM Tim Düsterhus <tim@bastelstu.be> wrote:
> > Hi > > On 6/17/22 18:06, Guilliam Xavier wrote: > >> https://github.com/php/php-src/pull/8819 > > > > Just so that it can't be said that it hasn't been asked: what about > > iterator_count(), and iterator_apply()? > > I also came across those, while implementing the PR, but I intentionally > did not touch them to keep the scope simple and because I think they are > less likely to be used generally.
Okay :)
> - `iterator_apply()` is easily replaced by a foreach loop, because the > return value is pretty useless, so it is not likely that a nested > function call is going to be used.
Well the same could be said about `array_walk()`... but anyway :p
> - For `iterator_count()` one could to `count(iterator_to_array($foo))` > if my proposal is merged. This come with a bit of overhead, but at least > it's not as clunky as `is_array($foo) ? $foo : iterator_to_array($foo)`
or as `is_array($foo) ? count($foo) : iterator_count($foo)`, for that matter ;)
> If a RFC is desired, then I'd likely include all three of them with a > vote for each, but I hope my proposal is simple enough to not require an > RFC.
Well I won't be the one asking for an RFC ^^ (and you're right that the `array_*` functions are far more numerous and [at least in my experience] used than the `iterator_*` ones)
-- Guilliam Xavier