Re: [VOTE] ImmutableIterable (immutable, rewindable, allows any key&repeating keys)

Hi Larry Garfield, Thanks for responding. > While I like the idea of an immutable collection, and the performance boost seems useful, this > proposal seems to go about it in a sloppy way. > > 1) Iterable doesn't seem like the right "family" for this. It is iterable, but > so are lots of other things. I'd suggested alternative names such as ImmutableKeyValueSequence, in https://externals.io/message/114834#114834 , but - It seemed as if the sentiment was very strongly against long names. I likely misjudged this. - Many names were suggested by only one person. I can't tell if there's a consensus from that. E.g. *Aggregate. - When I suggested names such as ImmutableKeyValueSequence before starting the vote, nobody had any feedback of it being better/worse than my previous proposals. > 2) I... have never seen anyone in PHP use "pairs" as a concept. I have no idea what > they're doing here. https://www.php.net/manual/en/class.ds-pair.php is a concept used in the DS PECL, e.g. https://www.php.net/manual/en/ds-map.first.php Proposing that as a new object type seemed excessive here. That reason is because PHP is (fairly) unique among languages with generic iterable types in that there's a key associated with values. I had to deal with this unusual situation somehow, and it's not a surprise that the solution is also unusual. Do you propose alternate solutions other than omitting the functionality? - Javascript only provides values in .next() - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols - Python only provides values https://docs.python.org/3/glossary.html#term-iterable - C++ iterators only provide values https://www.cplusplus.com/reference/iterator/ - And so on A generator-based workaround would be much slower ``` function userland create_iterable(iterable $pairs) { foreach ($pairs as [$key, $value]) { yield $key => $value; } } // $pairs = array_map(...array_filter(...fetchOrComputeData(...)...) $iterator = new ImmutableKeyValueSequence($pairs); ``` The other reason is that php has a large collection of internal and user-defined functions for dealing with arrays (sorting, filtering, etc), but few for iterables. toPairs and fromPairs allow easily converting values to this and back, then calling usort/filter for compact code. And if I provided fromPairs, toPairs seemed to make sense for completeness. > 3) The JsonSerialize seems out of place. It may make sense from another angle, but it just > sorta appears out of nowhere here. > > It almost feels like what you actually want is an immutable Dictionary class. Such would > naturally be iterable, countable, serializing makes some sense, a fromIterable() method would make > sense, etc. It would be useful for some but not all use cases. Especially use cases where keys aren't hashable, or where keys are repeated. Not all values would be hashable in a dictionary (e.g. circular data structures, self-referential arrays). There's a lot of open design questions for Dictionary in core, e.g. the name, and whether objects should be hashable, or namespace, or whether it may conflict with future native types. - And if a Hashable magic method or interface was added, then that might throw and make it impossible to store a generator. - And if large data structures are used (e.g. yielding extremely large keys or slow object hashing, the hashing would be slow even when the application didn't need hashing at all) > That I could get behind, potentially, although it also runs into the exciting question of type > restrictions and thus generics, which is where list type discussions go to die. :-) That's another possible obstacle to dictionary in core, but I hope not. Thanks, Tyson