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