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.
> 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