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:[email protected]> Sent: 2/27/2015 8:01 PM To: Andrea Giammarchi<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; es-discuss<mailto:[email protected]> Subject: Re: Cancelable promises On Fri, Feb 27, 2015 at 7:49 PM, John Lenz <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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" <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected]<mailto:[email protected]> https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected]<mailto:[email protected]> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
