RE: Cancelable promises

AsyncJS (http://github.com/rbuckton/asyncjs) uses a separate abstraction for cancellation based on the .NET CancellationTokenSource/CancellationToken types. You can find more information about this abstraction in the MSDN documentation here: https://msdn.microsoft.com/en-us/library/dd997364(v=vs.110).aspx

Ron
________________________________
From: John Lenz<mailto:concavelenz@gmail.com>
Sent: ‎2/‎27/‎2015 8:01 PM
To: Andrea Giammarchi<mailto:andrea.giammarchi@gmail.com>
Cc: public-script-coord@w3.org<mailto:public-script-coord@w3.org>; es-discuss<mailto:es-discuss@mozilla.org>
Subject: Re: Cancelable promises



On Fri, Feb 27, 2015 at 7:49 PM, John Lenz <concavelenz@gmail.com<mailto:concavelenz@gmail.com>> wrote:
Closure Library's promise implementation supports "cancel":

https://github.com/google/closure-library/blob/master/closure/goog/promise/promise.js#L502

A promise is cancelled only if all the "child" promises are also cancelled.

I did not say that correctly, a "parent" promise can be cancelled by a "child" it is the only child or all the children cancel.  A parent can alway cancel its children (to the children this is simply "reject").  It does add a significant amount of complexity to the promise implementation but it is for the most part contained there.

I don't believe that "cancel" can be added after the fact and an alternative (subclass or otherwise) is needed.


On Thu, Feb 26, 2015 at 11:43 PM, Andrea Giammarchi <andrea.giammarchi@gmail.com<mailto:andrea.giammarchi@gmail.com>> wrote:
AFAIK bluebird did:
https://github.com/petkaantonov/bluebird/blob/master/API.md#cancelerror-reason---promise

But I agree once you've made Promises more complex than events ( xhr in this case ) nobody wins :-/

Although, specially for fetch or anything network related, there **must** be a way to bloody cancel that!

....right?


On Fri, Feb 27, 2015 at 7:31 AM, Kevin Smith <zenparsing@gmail.com<mailto:zenparsing@gmail.com>> wrote:

The discussion on that github issue surrounding promise subclassing makes my head spin, especially when it comes to working out how cancelation is supposed to flow through a graph of promise dependencies.  We should be wary of adding complexity to the core.

The simple way to view the situation is to say that promises are simply transparent containers for asynchronous values. Control capabilities should therefore be represented by a separate abstraction. This will help keep complexity at the edges.

Has any library experimented with the cancelation token approach yet?

On Feb 27, 2015 1:46 AM, "Anne van Kesteren" <annevk@annevk.nl<mailto:annevk@annevk.nl>> wrote:
As a heads up, there's some debate around the fetch() API how exactly
request termination should work and how that affects promises:

  https://github.com/slightlyoff/ServiceWorker/issues/625

The WebRTC WG has also been discussing canceling in the context of
terminating a request for permission from the user. I think they
decided to postpone for now until there's a bit more progress on what
cancelable promises means, but I would not expect everyone to wait
forever.


--
https://annevankesteren.nl/
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss