Just some terminology questions for this new proposal... From: Tab Atkins Jr. [[email protected]]
> 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. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
