Promises

Andreas Rossberg rossberg at google.com
Wed Nov 7 03:11:08 PST 2012


On 6 November 2012 20:55, David Herman <dherman at mozilla.com> wrote:
> - a way to create promises that don't expose their internal "resolve me" methods, etc. so they can be delivered to untrusted clients, e.g.:
>
>     var [internalView, externalView] = Promise.makePair();
>     "resolve" in internalView // true
>     "resolve" in externalView // false

Indeed. I think this is an issue where many promise/future libraries
are confused/broken. FWIW, when creating a concurrent language called
Alice ML some 15 years ago we thought about this quite extensively,
and ended up introducing the following separation of concepts:

* Futures are handles for (potentially) unresolved/asynchronous
values, on which you can wait and block -- but you cannot directly
resolve them.

* Promises are explicit resolvers for a future. More specifically,
creating a promise creates an associated future, which you can safely
pass to other parties. Only the promise itself provides the fulfill
method (and related functionality) that enables resolving that future.

In other words, futures provide synchronisation, while promises
provide resolution.

Incidentally, that's also exactly the model and naming that C++11 picked.

/Andreas


More information about the es-discuss mailing list