W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Futures

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 26 Apr 2013 11:10:49 -0700
Message-ID: <CAAWBYDCyNfAnNEUqxyavxhX4eb=gysW12oi_hkm03zPwnKENuA@mail.gmail.com>
To: Kevin Smith <zenparsing@gmail.com>
Cc: David Sheets <kosmo.zb@gmail.com>, Brendan Eich <brendan@mozilla.com>, "Mark S. Miller" <erights@google.com>, Douglas Crockford <douglas@crockford.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Norbert Lindenberg <w3@norbertlindenberg.com>, Markus Lanthaler <markus.lanthaler@gmx.net>, EcmaScript <es-discuss@mozilla.org>
On Fri, Apr 26, 2013 at 11:03 AM, Kevin Smith <zenparsing@gmail.com> wrote:
> The current DOM spec, in code:

Or, much more simply:

* Future.accept takes a Foo and returns a Future<Foo>.
* Future.resolve takes either a Foo or a Future<Foo>. In either case,
it returns a Future<Foo>.
* In Future.then(cb), the cb is expected to have the signature (Foo ->
Future<Foo>). It has some extra magic that allows you to return a
plain Foo, and treats it the same as if you returned a Future<Foo>.
Effectively, this means that it passes the return value through
Future.resolve() to normalize it into a Future<Foo>.
* You can totally make nested Futures deliberately by doing something
like "Future.accept(Future.accept(5))".

~TJ
Received on Friday, 26 April 2013 18:11:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC