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>
> wrote:
> > 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
> Promise/Future for JavaScript a few years back I was primarily invested in
> 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
> FutureResolver#resolve.
> >
> > 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
> monads).
>
> (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.)
>
> ~TJ
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130424/7eefa5ec/attachment.html>


More information about the es-discuss mailing list