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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
