Hi Johannes, 2018-06-20 18:40 GMT+02:00 Johannes Schlüter <johan...@schlueters.de>:
> > Is there any reason not to extend the existing functions to also allow > arrays? > Yes, this was discussed in the PR on GitHub: https://github.com/php/php-src/pull/3293#issuecomment-397082988 There are two main reasons to not do that: 1) Naming: iterator_*(), as the name suggests, is supposed to work with iterators. Making it work with arrays would be highly confusing. 2) Not altering/reusing existing functions: Changing behavior of existing functions that exist for many years is also confusing for consumers. In both cases this would make code harder to understand (i.e. taking version of PHP into efffect). > Also for the count one: Mind that iterator_count()/iterable_count() > doesn't respect the Countable interface and consumes the iterator, > which might not be resetable. A slightly better choice might be > > (is_array($iterable) || implements_countable($iterable)) ? > count($iterable) : iterator_count($iterable) > > And even then I would put a warning sign against blindly using it on > any iterator. > Just like with existing iterator_count(), this is up to the consumer to decide whether it's safe or not to use (especially with generators). It has exactly the same benefits and drawbacks. Also I'm not sure whether this is a downside of *_count() or not, IMHO it's designed specifically to count an iterator that is not Countable. So for an iterable, one may prefer: is_countable($value) ? count($value) : iterable_count($value) But again, this is up to the consumer to decide whether it's safe or not. johannes > Thanks, Michael