Promises

Tom Van Cutsem tomvc.be at gmail.com
Wed Nov 7 08:57:54 PST 2012


2012/11/7 Kevin Smith <khs4473 at gmail.com>

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

While we're talking nomenclature: the terms "promise" and "future" also
appear, with roughly the semantics described by Andreas in Scala's API [1]
and Clojure's API [2] (both very recent APIs). I know MarkM dislikes the
use of these terms to distinguish synchronization from resolution, as he
has long been using those same terms to distinguish traditional "futures",
which provide a .get() method blocking the calling thread and returning the
future's value when ready (as in e.g. Java), from "promises", which only
provide a non-blocking "when" or "then" method requiring a callback, never
blocking the event loop thread (as in all the Javascript promise APIs).

To my mind, the term "future" is still very closely tied to blocking
synchronization. YMMV.

There's a helpful Wikipedia article that compares and contrasts some uses
of the terms [3].

Cheers,
Tom

[1] http://docs.scala-lang.org/sips/pending/futures-promises.html
[2] http://www.michaelharrison.ws/weblog/?p=239
[3] http://en.wikipedia.org/wiki/Futures_and_promises
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121107/2e613d91/attachment-0001.html>


More information about the es-discuss mailing list