Re: Cancellation architectural observations

following up from this
https://github.com/whatwg/fetch/issues/27#issuecomment-86987752 , and most
likely late to the party.

How about cancel-ability done this way ?

```js

var p = new Promise(function (res, rej, cancel) {
  // resolved in 1 second via random value
  var t = setTimeout(res, 1000, Math.random());
  // if meant to be canceled
  // we define internally what to do
  cancel(function () {
    clearTimeout(t);
  });
});

// whenever/if needed
p.cancel().then(...);
```

The exposed cancel-ability is arbitrary provided internally so that if
missing, an error is thrown while if provided it sets the internal state of
the promise as `canceled` in case it's different from `resolved` or
`rejected`

It gives the ability to react, if a `then` is attached, or the ability to
ignore, if nothing happens to the returned, non cancel-able, Promise.

This avoids exposing to the outer world what happens inside the Promise and
provides arbitrary ability to cancel one.

A cancel-able Promise is one that defined such behavior, which by default
is throwing if that's not defined internally.
This would solve already many cases I have in mind, via users, or
UserAgent, and legitimately behind the scene without any need to expose any
internal logic.

How to resolve or throw other attached promises? Well, `p.cancel().then()`
resolves, while `p.cancel().throw()` does not. `p.cancel()`, without then
or throw would simply throw away pending promises as explicit `ignore`
intent.

How bad does it look and what am I screwing up in here in terms of Promises
philosophy?

Best Regards







On Wed, Mar 4, 2015 at 8:01 PM, Ron Buckton <Ron.Buckton@microsoft.com>
wrote:

> > new Promise(resolve => doLater(resolve, cts.token)).then(handleResult);
> > setImmediate(() => cts.cancel());
>
> >
> > In this scenario cancel would be called right after the resolve method
> > is called, but before handlerResult is called. For this to work with a
> > cancellation token you would need to pass the token to every step in
> > the chain to both stop work being done and to ignore the
> > result/prevent a handler from being called. Wouldn't it be better if
> > the promise chain took care of this for the programmer?
>
> I can be convinced that CancellationToken registrations should be invoked
> asynchronously, though I wonder if then CancellationTokenSource#cancel
> should return a Promise to observe any errors that occur.
>
> Ron
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>