Futures (was: Request for JSON-LD API review)
Mark S. Miller
erights at google.com
Wed Apr 24 10:20:12 PDT 2013
On Wed, Apr 24, 2013 at 10:14 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
> On Wed, Apr 24, 2013 at 10:10 AM, Ron Buckton <rbuckton at chronicles.org>
> > I'm not yet sold on having both accept and resolve on the resolver. In
> the .NET world, a Task for a Task (e.g. Task<Task<T>>) is just that, and
> you have to unwrap the Task with something like a TaskCompletionSource<T>,
> which is explicitly like FutureResolver#accept. Libraries like Q.js
> automatically assume a Future of a Future is just a Future, implicitly
> unwrapping like FutureResolver#resolve. When I started digging into
> the first camp due to my experience with Futures in a type-safe language.
> Actively using Futures in a dynamic language has pushed me more towards
> simplifying a nested Future into a single Future due to its simplicity. I
> can see how providing both mechanisms could possibly satisfy developers in
> either camp, but could be confusing to API consumers if one library
> generally uses FutureResolver#accept and another library generally uses
> > Is there a lot of interest to support both, or any previous discussion
> on the topic that I could peruse to understand the arguments for having
> either "accept", "resolve", or both?
> Q and similar libraries don't actually assume that a Future<Future<x>>
> is a Future<x>.
Yes it does. Except of course that we call these "promises". Please see the
extensive discussions on the Promises/A+ site about why this flattening
behavior is important.
> (Well, not all of them.) Properly, they're treating
> Future as a monad, and .then() as the monadic operation, so you can
> "chain" future-returning functions easily (this is the core value of
> (Some libraries do indeed fully flatten the types, but that's a bad
> behavior imo, as far as I can tell not what DOM Futures do.)
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss