Promises Consensus

Domenic Denicola domenic at domenicdenicola.com
Wed Jul 31 10:49:00 PDT 2013


Just some terminology questions for this new proposal...

From: Tab Atkins Jr. [jackalmage at gmail.com]

> whatever p resolves to, gets passed to the flatMap() callbacks.

What does "resolves" mean in this context? I don't believe you are using it in the same way that it is used in Promises/A+ or DOM Promises. For example, using the existing definition, you could resolve `p` to a forever-pending promise; I doubt you'd want to pass that forever pending promise to either (both?) of the flatMap callbacks.

> if p accepts to a promise-like, the callbacks get moved down to that until it either accepts with a non-promise-like, or rejects.

What does "accepts" mean?

> Promise.every() will eventually resolve to an array of non-promise-likes.

Again, what are you meaning by "resolve" here? Promises don't "resolve" to anything, so this is confusing.

> We can't just use magic internal operations to detect when the returned value resolves, so the output promise will have to register callbacks on it.

Same question.

> This may have performance implications - is it possible that we just do eager resolution now, but later have detection for lazy promises getting returned and switch to lazy behavior in just those cases?

Here I believe you are using "resolution" in the same sense as Promises/A+ or DOM Promises, but differently from all the above uses.

> Should we reject with a TypeError, or fall back to using .then() resolution semantics?

Again this seems correct, but in contradiction to earlier uses.



More information about the es-discuss mailing list