Re: [whatwg/dom] Define a 'CancellationController' and 'CancellationSignal' interface. (#434)

@Domenic fwiw, my perception is that one attempt at cancellation was tried and failed for reasons that are not entirely clear (at least to me). If there is good rationale for why this proposal is better than a host agnostic one, I'm glad to hear it, but I'll be very sad if the only reason is political. There is no doubt that the TC39 proposal that was ultimately rejected is way more involved than this proposal. I believe that a cancellation token approach very similar to this proposal has always been most likely to succeed in TC39 and, as far as I can tell, has not been tried. We should try it. What am I missing?

Anyway, thinking out loud:

I'm intrigued that this proposal is very similar to cancellation tokens as implemented in other systems (and as discussed by Ron and others within TC39)... but not exactly. Eg. it doesn't seem to have much support for compositing cancellation signals. Has this been considered?

IMO I'd like to see that the thrown thing on cancellation does not inherit from "Error". Having a separate top-level object makes checking in some cases easier, perhaps, and gives us a clean object hierarchy to extend later. It's also similar to the Ruby object hierarchy where certain classes of errors are a separate branch of an inheritance tree and are not caught by the normal "catch" block. Doing something similar might make it easier in the future to add similar language-level integration. At the very least it could make pattern matching more clear (using strawman syntax, please forgive me, and where Error here is an identifier pattern that is essentially doing an instanceof check):

```
catch (s) {
  match (s) {
    |> Error: throw s;
    |> CancelSignal: handleCancel();
}
```


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/434#issuecomment-292610793