> In other words, futures provide synchronisation, while promises
> provide resolution.
>
This is exactly the API that Q (and it's derivatives) use, although the
nomenclature is different. In Q, the "future" is called a promise, and the
"promise" is what you get from calling defer():
let { resolve, reject, promise } = Q.defer();
I think the nomenclature you've provided is superior. Using those names
we'd have an API that looks something more like this:
let promise = new Promise();
let future = promise.future;
// Futures have a then method, ala Promises/A+
future.then(val => { ... });
// Promises are resolved using methods on the promise object:
promise.resolve(val);
promise.reject(val);
The aesthetic issue I have with Promises/A+ is that the error handling
interface is ugly:
future.then(val => {
...
}, err => {
...
});
In all of our APIs we try to avoid placing callbacks in non-terminating
argument positions, which this violates.
The only hard part that isn't really addressed by currently library
implementations is error handling. I feel pretty strongly that rejections
(and by extension, errors thrown from `then` callbacks), should ALWAYS be
observable. In other words, if a rejection is not observable via error
listeners at the time when error listeners should be called, then an
unhandled error should be thrown by the runtime.
In my usage of promises I have never wanted anything other than this
behavior.
- Kevin
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
