Hi Marco Pivetta,
> I see the RFC as valuable but:
>
> * __serialize and __unserialize are out of scope: this depends on
>the contents of it, and there's no point in implementing them
> * __set_state should also not be implemented: var_export() like any
>other object and it should be fine
> * jsonSerialize also depends on the contents, and shouldn't be exposed
>
> All of this is not part of what should be in a reusable iterator.
This is an IteratorAggregate implementation and all of the contents of the inner iterable are
eagerly evaluated in the constructor.
I'd also considered names such as ImmutableIteratorAggregate, ImmutableKeyValueSequence or
ImmutableEntrySet, but was unhappy with all of the names (excessively long, misleading, ambiguous,
etc),
and prior discussion on the mailing list lead me to believe short names were widely preferred over
long names https://externals.io/message/114834#114812
If it was lazily evaluated such as proposed in https://wiki.php.net/rfc/cachediterable#future_scope
, I'd agree that __serialize, __unserialize,
json_encode, etc likely didn't belong in a lazily evaluated data structure,
but the goal was creating a reusable data structure
(e.g. that could be used to store key-value sequences from any source compactly (e.g. generators)
and be serialized
and persisted to memcached, redis, a file, static array, etc)
Cheers,
Tyson