On Wed, Nov 14, 2012 at 11:37 AM, Tom Van Cutsem <[email protected]> wrote:
> 2012/11/14 Andreas Rossberg <[email protected]> > >> On 14 November 2012 18:41, Mark S. Miller <[email protected]> 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! :-) > OTOH, the Argus promises were where promise pipelining < http://en.wikipedia.org/wiki/Futures_and_promises#Promise_pipelining> was invented, and this is a key feature of our distributed promises via .send/.post. In this way, the Argus promises are the closest to ours. > > Cheers, > Tom > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
