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
