- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 26 Apr 2013 11:10:49 -0700
- 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