tc39 / proposal-joint-iteration

a TC39 proposal to synchronise the advancement of multiple iterators
https://tc39.es/proposal-joint-iteration
70 stars 2 forks source link

Alternative naming for `zipToObject` #27

Closed acutmore closed 4 months ago

acutmore commented 5 months ago

This thought only came to me during the last presentation when the proposal was about to get to stage 2.7 - while this is a little late at least we're not at stage 3 yet so might still be some wriggle room.

I am one of the champions for https://github.com/tc39/proposal-await-dictionary, which has some API similarities.

At a type level:

Promise.all (Array<Promise<T>>) ->  Promise<Array<T>>

Iterator.zip(Array<Iterator<T>>) -> Iterator<Array<T>>

If there is Iterator.zipToObject it may be natural to mirror this for the "await dictionary" proposal. Leading to:

Iterator.zipToObject(Object<Iterator<T>>) -> Iterator<Object<T>>

Promise.allToObject (Object<Promise<T>>) ->  Promise<Object<T>>

This other proposal doesn't have to follow the naming style, but it feels advantageous if they could match. So I am wondering, with this other wrapper type in mind do we still want to go with toObject or maybe an alternative would be preferred?

Some potential downsides with toObject: arrays are also objects, and the input is also expected to be an object. So the mapping isn't turning something into an object. It's turning the object inside out: Obj<Box<T>> -> Box<Obj<T>>.

Some starter suggestions:

bakkot commented 5 months ago

I'll also throw out zipKeyed.

acutmore commented 4 months ago

We discussed this today in Bloomberg's pre-plenary-prep and a few people were +1 on @bakkot's zipKeyed. As the language's vocabulary already includes Object.keys, Reflect.ownKeys.