Futures (was: Request for JSON-LD API review)

Tab Atkins Jr. jackalmage at gmail.com
Wed Apr 24 10:14:09 PDT 2013


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>.  (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


More information about the es-discuss mailing list