concavelenz at gmail.com
Fri Feb 27 20:00:35 PST 2015
On Fri, Feb 27, 2015 at 7:49 PM, John Lenz <concavelenz at gmail.com> wrote:
> Closure Library's promise implementation supports "cancel":
> 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 at gmail.com> wrote:
>> AFAIK bluebird did:
>> 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!
>> On Fri, Feb 27, 2015 at 7:31 AM, Kevin Smith <zenparsing at gmail.com>
>>> 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 at 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:
>>>> 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
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>> es-discuss mailing list
>> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss