> -----Original Message-----
> From: Tab Atkins Jr. [mailto:[email protected]]
> 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 <[email protected]> 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.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
