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
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 functioniterable_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--
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
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 functioniterable_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--
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?
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 functioniterable_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
Just so that it can't be said that it hasn't been asked: what about
iterator_count(), and iterator_apply()?
Regards,
--
Guilliam Xavier
Hi
https://github.com/php/php-src/pull/8819Just so that it can't be said that it hasn't been asked: what about
iterator_count(), anditerator_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 tocount(iterator_to_array($foo))
if my proposal is merged. This come with a bit of overhead, but at least
it's not as clunky asis_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
Hi
https://github.com/php/php-src/pull/8819Just so that it can't be said that it hasn't been asked: what about
iterator_count(), anditerator_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 tocount(iterator_to_array($foo))
if my proposal is merged. This come with a bit of overhead, but at least
it's not as clunky asis_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