> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage at gmail.com]
> Sent: Friday, April 19, 2013 5:18 PM
> To: Kevin Gadd
> Cc: Ron Buckton; es-discuss
> Subject: Re: Futures (was: Request for JSON-LD API review)
> 
> On Fri, Apr 19, 2013 at 4:02 PM, Kevin Gadd <kevin.gadd at gmail.com> wrote:
> 
> One simple possibility would be to just expose accept/resolve/reject on the
> returned Future itself.  Calling any of these cancels the Future (if the Future
> has a notion of cancellation), and forces it to adopt the passed state as
> appropriate.  The constructor would take two callbacks, one for normal
> operation (called immediately) and one to handle cancellation (called when
> needed).  This has the nice benefit that a consumer can provide a default
> value for other consumers to use, and it doesn't require any new codeflow
> channels.

I'd be more interested in having a creatable FutureResolver with a .future accessor property for those cases. Given the current API, its possible (but not pretty) to do something like:

function someCancelable() {
  var cancel;
  var future = new Future(function(resolver) { 
    cancel = function() { resolver.reject("cancelled"); }
    // other async work
  })
  return { cancel: cancel, future: future };
}

var { cancel, future } = someCancelable();
future.then(...).done(...);
elt.onclick = cancel;

Though this still wouldn't really prevent unnecessary tasks from being queued on the dispatcher.

> It would be so nice if JS had multiple return values, so we could let
> cancellable future-returning APIs just return a naked resolver as their second
> value, and only clueful call sites would need to care about it.  ^_^  Instead,
> we'll probably need to have API variants that instead return something like a
> Deferred, or that return a pair of a future and a resolver.

That sounds like what I just mentioned in https://gist.github.com/rbuckton/5424214.

> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage at gmail.com]
> Sent: Friday, April 19, 2013 5:18 PM
> To: Kevin Gadd
> Cc: Ron Buckton; es-discuss
> Subject: Re: Futures (was: Request for JSON-LD API review)
> 
> On Fri, Apr 19, 2013 at 4:02 PM, Kevin Gadd <kevin.gadd at gmail.com> wrote:
> 
> One simple possibility would be to just expose accept/resolve/reject on the
> returned Future itself.  Calling any of these cancels the Future (if the Future
> has a notion of cancellation), and forces it to adopt the passed state as
> appropriate.  The constructor would take two callbacks, one for normal
> operation (called immediately) and one to handle cancellation (called when
> needed).  This has the nice benefit that a consumer can provide a default
> value for other consumers to use, and it doesn't require any new codeflow
> channels.

I'd be more interested in having a creatable FutureResolver with a .future accessor property for those cases. Given the current API, its possible (but not pretty) to do something like:

```js
function someCancelable() {
  var cancel;
  var future = new Future(function(resolver) { 
    cancel = function() { resolver.reject("cancelled"); }
    // other async work
  })
  return { cancel: cancel, future: future };
}

var { cancel, future } = someCancelable();
future.then(...).done(...);
elt.onclick = cancel;
```

Though this still wouldn't really prevent unnecessary tasks from being queued on the dispatcher.

> It would be so nice if JS had multiple return values, so we could let
> cancellable future-returning APIs just return a naked resolver as their second
> value, and only clueful call sites would need to care about it.  ^_^  Instead,
> we'll probably need to have API variants that instead return something like a
> Deferred, or that return a pair of a future and a resolver.

That sounds like what I just mentioned in https://gist.github.com/rbuckton/5424214.