s/Future/Promise/g - Infrequently Noted

gre- The idl now clearly indicates the "resolve" and "fulfill" methods in the Promise interface are static. These would mint new Promise objects and immediately resolve them and wouldn't act on a existing Promise object.

Note: ({})['catch'] works on IE8.

And I got together with Anne today to help him update the spec to the harmonious compromise. Should be finished sometime this next week. Yay!

Hi Alex, Thanks for bringing this up.

I have one year of experience daily working with the Q library, and I found this current spec quite disappointing.

First, I really like the independence between the "deffered" object (called here the resolver) and the "promise" object which is a object with a .then() function. In Q, you create a deffered with a Q.defer(), and you get the promise of it with deffered.promise.

Here, the spec Promise interface contains both the .then method and the .resolve/.reject functions, why that !?

Isn't the "PromiseResolver" interface useless if we can already resolve from a "Promise", IMO that's ambiguous you can do the same thing with 2 different APIs.

Second, I don't really like that new Promise(callbackTakingAResolver) API. I found very ugly that you need to "externalize" the resolver variable from the callback (e.g. in the Promise.idl design consensus).

As a bonus, I would love the API to have a .progress like Q does. Q also provides a lot of useful functions, but we can hopefully still build something on top of that native API.

Also, good luck for making a polyfill of it for IE (8) : catch is a reserved word,

({}).catch = 1 fail on IE (tested on IE8).

Hey Brett,

Good question. Promises are the sort of low-level thing you might imagine Yeild de-sugaring into in order to deliver values across CPS-transformed code bodies.

How they interact when you're using them together and not playing in one world or the other is a question for how the de-sugaring eventually gets written. What sorts of patterns are you encountering there?

Hey Alex,

If you scroll down, you'll see that the list is mostly the same in Blink, indicating spec failings, not just impl issues. What's needed now is the Extensible Web perspective: it challenges spec authors on these points and lays the groundwork for change.

If you want to help, filing bugs in the W3C bug trackers against these specs is the next step.

This is quietly gamechangingly stuff. Keep up the awesome work.

BTW that linked list of create APIs that don't have constructors in Firefox is a doozy. The number of SVG elements alone! (And I think of Firefox SVG support as being generally strong.) What's going on here, and what can be done? Without finger-pointing, maybe there is another good post here.

How do you see Promises interacting with Yield? I find promises + yield to be the most powerful abstraction in building real things.

http://www.onebigfluke.com/2012/07/futures-as-design-pattern-for.html