Re: [w3ctag/design-reviews] AbortSignal.timeout() (Issue #711)

Hi @domenic,

We looked at this again today.
On the linked WHATWG issue you've [made the comment](https://github.com/whatwg/dom/issues/1110#issuecomment-1242811392):

> I think this proposal is a bad idea and would be poor API design. The constructor of an object should vend its fundamental capabilities. It should not provide a syntactic shortcut for saving an extra line of setup, by connecting the constructed object to a totally different part of the web platform. (In this case, the event loop and timer subsystem.)
> 
> Furthermore, `AbortController`s created in this way are harder to reason about. They have a hidden, implicit caller of `abort()`, which you cannot see. You have to know that whoever created it, hid such a call from you in the constructor. You can no longer scan for all `abort()` calls to find all ways the controller might be aborted.
> 
> I don't think we have evidence that the use case in question (roughly, creating an `AbortController` that is controlled by both a timeout and other callers) is very popular. And if we did, I don't think we have evidence that being explicit, using `setTimeout()`, is a huge burden. (Note that `AbortSignal.any()` is not actually needed, you can do `const controller = new AbortController(); setTimeout(() => controller.abort(), 5000);` and then pass `controller` onward.)
> 
> I hope we keep the `AbortController` constructor simple and focused on its core capabilities. Any syntactic sugar should continue to be done at the `AbortSignal` level, like we've done with `AbortSignal.timeout()` and like we're proposing to do with `AbortSignal.any()`. Static factory methods there both avoid messing up the API construct of the controller's constructor, and can pull their own weight by saving more than a single extra line (since they abstract away the entire `AbortController` object).

There are several design principles implicitly assumed in this message, and we'd like to discuss them separately, because we may or may not agree, and in any case it's good to get the benefit of a documented discussion that is separate from this particular issue. 

For example, things like:

- "The constructor of an object should not provide a syntactic shortcut for saving an extra line of setup"
- "It should not [connect] the constructed object to a totally different part of the web platform. (In this case, the event loop and timer subsystem.)"
- That having a hidden implicit call to `abort()` is a bad idea — why?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/711#issuecomment-1358011570

You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/711/1358011570@github.com>