Re: Future cancellation

On May 1, 2013 8:21 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>
> On Wed, May 1, 2013 at 12:16 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> > However with this approach you get an API which automatically simply
> > works as an API returning a Future in case you don't need to abort the
> > operation or display its progress:
> >
> > handleResult(doSomeOperation());
> > or
> > return doSomeOperation();
> > or
> > doSomeOperation().then(val => displayResult(val));
> >
> > I.e. if you don't care about the operation part, the API simply works
> > as any other API which returns a promise. This seems like a very nice
> > thing. The only "cost" of this API is that it doesn't compose when you
> > compose the future, but neither does the dispose object in the tuple
> > approach.
>
> The other cost is an inherent capability leak - *unless* you purposely
> strip it of its cancelability, passing it around to anything else
> gives the "anything else" the ability to cancel your promise as well.
> The tuple approach doesn't have this issue - the promise and the
> canceler/resolver are inherently separated, and you have to purposely
> hand the canceler/resolver off to other code for it to have any
> powers.

This is a problem that the current XHR API is suffering from too. Has that
been a problem in reality?

With XHR you can even affect the values that other consumers are receiving
by setting .response type. Again, does anyone have examples of when this
has been a problem?

I feel like attempting to solve this problem will mean that we need to
split a lot of interfaces into lists of objects, each representing a
capability. This seems like it will very quickly lead to an unmanageable
mess.

Wrapping a CancelableFuture in a normal Future seems like an acceptable
solution which only adds complexity in the much more rare case that someone
cares about capabilities.

/ Jonas