2012/11/7 Kevin Smith <[email protected]> > > 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
