Re: Make iterator_to_array() accept all iterables
| From: | Guilliam Xavier | Date: | Mon, 20 Jun 2022 12:07:48 +0000 |
| Subject: | Re: Make iterator_to_array() accept all iterables | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-118006@lists.php.net to get a copy of this message | ||
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