Re: [whatwg/dom] Specify that AbortController#abort() be bound to AbortController instance (#981)

First, let me apologize for my "flawed" comment (😳).  That came across a bit sharper than intended.   And I'll be the first to acknowledge that the `{signal, abort}` tuple I've proposed  is basically the same thing as AC, the only difference being that it doesn't carry the weighty formality of a class, and has `abort` well and truly bound to `signal`.  So it's not like I'm offering a complete redesign here.  Anyhow... sorry about that.

> details on the history here

@jakearchibald : Thanks for the link to the previous discussion(s).    I was sure such discussion existed but wasn't sure where.   I'm afraid I don't have time to read through that in detail at the moment, but I'll try to catch up on it later (maybe this weekend?)

> This is an antipattern. It means abort is being called with an Event object

Having been bitten by [Firefox's lateness argument](http://benalman.com/news/2009/07/the-mysterious-firefox-settime/) back in the day, I appreciate this concern I question whether this is something WHATWG should be policing, though.   If a user is concerned with this, `() => abort()` works.

I think @bathos has the right path forward here.  Treat AC/AS as the control flow primitives and build utilities on top of that.

-- 
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/issues/981#issuecomment-845309163