Hi Alex, > > I've created a new RFC https://wiki.php.net/rfc/cachediterable adding > > CachedIterable, > > which eagerly evaluates any iterable and contains an immutable copy of the > > keys and values of the iterable it was constructed from > > > > A heads up - I will probably start voting on > > https://wiki.php.net/rfc/cachediterable this weekend after > > https://wiki.php.net/rfc/cachediterable_straw_poll is finished. > > > > Any other feedback on CachedIterable? > > Thanks for explaining 4 months ago about my concern. > I think I understand the main real impact of an eager iterable cache vs a > lazy iterable cache from a functional point of view: > - exceptions are thrown during construction vs during the first iteration > - predictable performance also on the first iteration. > > How did you gather the information that eager implementation is more valuable > than lazy one? I'm mostly curious also how to assess this as technically to > me it also looks the other way around. Maybe mention that in the RFC. > I was even thinking that CachedIterable should be lazy and an > EagerCachedIterable would be built upon that with more methods. Or have it in > the same class with a constructor parameter.
One of the reasons was size/efficiency. Adding the functionality to support lazy evaluation would require extra properties to track internal state and extra checks at runtime, point to the original iterable and the functions being applied to that iterable - so an application that creates lots of small/empty cached iterables would have a higher memory usage. Having a data structure that tries to do everything would do other things poorly (potentially not support serialization, use more memory than necessary, have unintuitive behaviors when attempting to var_export/var_dump it, surprisingly throw when being iterated over, etc) > Also, being able to have a perfect userland implementation, not very complex, > even considering the lower performance, is not that good for positive voting > from what I remember from history... 1. The userland polyfill included in the RFC is an incomplete implementation that only supports iteration. It's meant to be as fast as possible at the cost of memory usage. It's not even an IteratorAggregate, doesn't support json encode, createFromPairs, and many other functions. 2. Virtually all of the spl iterables that don't deal with filesystems can be reimplemented in userland. (https://en.wikipedia.org/wiki/Turing_completeness) Even complicated extensions such as redis or memcached can be reimplemented in userland on top of sockets, but with higher cpu usage than native extensions (https://github.com/predis/predis/blob/main/FAQ.md#predis-is-a-pure-php-implementation-it-can-not-be-fast-enough) The benefit of having data structures internally is the fact that developers who learn them can use them in any project without adding dependencies (even in single file scripts) and that applications using CachedIterable would have much better performance Also, you and Levi have pointed out that iterable/iterator functionality is traditionally on-demand (https://en.wikipedia.org/wiki/Lazy_evaluation) (e.g. iterables such as CallbackFilterIterator, RecursiveArrayIterator, etc) As a result, I'm thinking CachedIterable is really not a good name for the eagerly evaluated data structure I'm proposing here, and that there was confusion about how the data structure behaved when the name CachedIterable was suggested. If functionality like that described in https://externals.io/message/114805#114792 was added, it could use the name CachedIterable instead. So I'm probably changing this to `ImmutableTraversable` as a short name for the functionality, to make it clear arguments are eagerly evaluated when it is created. (ImmutableSequence may be expected to only contain values, and would be confused with the ds PECL's https://www.php.net/manual/en/class.ds-sequence.php) Thanks, Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
