Closed pennane closed 2 months ago
Even in a world with tuples, arrays will continue to be the default: that's already entrenched in things like Map.prototype.entries
, Object.groupBy
, JSON.parse
, etc. It's would be fine to potentially add a zipImmutable
or something, but the default and shortest name should be the array-producing thing.
I see now that you are right. Moreover zipImmutable
and zipKeysImmutable
are not as horrible as I thought they'd be before actually writing them down.
I have a grudge with js arrays, but as much I'd like there isn't really a way around it.
Thanks for a quick answer. I'll close this as its not really of futher priority.
Hi,
I was wondering whether the Record and Tuple proposal should be considered alongside this proposal? I believe it makes sense, given how many languages that support tuples also have the
zip
methods utilize them. (as far as I understand)I like to envision a future for JavaScript with real tuples and records. If these two proposals are to coexist, I think it's fair to consider how they should behave together.
As I see it, there are currently
Iterator.zip
andIterator.zipKeyed
, which I find potentially conflicting if we were to introduceTuple
andRecord
counterparts in the future.If the method names were changed to
Iterator.zipToArrays
andIterator.zipToObjects
, as I understand they were before, it would be natural to also add theIterator.zipToTuples
andIterator.zipToRecords
counterparts when the time comes.It could also make sense to leave
zipToArrays
as the conceptual default, and keep its name asIterator.zip
whilst keeping the others in thezipToTypes
format, but in the long run, I see that being counterproductive.