Promises

Tom Van Cutsem tomvc.be at gmail.com
Wed Nov 14 11:37:33 PST 2012


2012/11/14 Andreas Rossberg <rossberg at google.com>

> On 14 November 2012 18:41, Mark S. Miller <erights at google.com> wrote:
> > Either way, Scala's
> > unfortunate choice clearly violates this history in a confusing manner,
> so
> > I'd classify it as #4. Let's not repeat Scala's mistake.
>
> Just to reiterate, it's not just Scala, but more importantly also C++,
> Java (to some extent), and several less mainstream languages. That is,
> this use of terminology has quite a bit of history of its own, dating
> back almost as far as E (and having developed more or less
> independently).


I still think futures connote strongly with blocking synchronization. If
we'd add a concept named "future" to JS on the grounds that the same
concept exists in Java and C++, developers will reasonably expect a
blocking future.get() method.

In my experience, the term "promise" is much more associated with
non-blocking synchronization through .then or .when callback chaining
(although ironically the name derives from Argus, which featured blocking
promises. Argh! :-)

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121114/e71f5ac7/attachment.html>


More information about the es-discuss mailing list