Re: [whatwg/dom] Add AbortSignal.any() (PR #1152)

@shaseley commented on this pull request.



> @@ -1779,8 +1779,11 @@ constructor steps are:
 <a>this</a>'s <a for=AbortController>signal</a>.
 
 <p>The <dfn method for=AbortController><code>abort(<var>reason</var>)</code></dfn> method steps are
-to <a for=AbortSignal>signal abort</a> on <a>this</a>'s <a for=AbortController>signal</a> with
-<var>reason</var> if it is given.
+to <a for=AbortController>request abort</a> on <a>this</a> with <var>reason</var> if it is given.

SGTM, changed to signal abort. FWIW request abort was inspired by the note (near [here](https://dom.spec.whatwg.org/#example-throwifaborted)) about how changes to a signal represent the wishes of an AbortController but might be ignored.

> @@ -1802,6 +1806,11 @@ interface AbortSignal : EventTarget {
  <dd>Returns an {{AbortSignal}} instance whose <a for=AbortSignal>abort reason</a> is set to
  <var>reason</var> if not undefined; otherwise to an "{{AbortError!!exception}}" {{DOMException}}.
 
+ <dt><code>AbortSignal . <a method for=AbortSignal lt=any(signals)>any</a>(<var>signals</var>)</code>
+ <dd>Returns an {{AbortSignal}} instance which will be aborted if any of <var>signals</var> is

Done.

>  them. For instance, if the operation has already completed.
 
-<p>To <dfn export for=AbortSignal>signal abort</dfn>, given an {{AbortSignal}} object
+<p>To <dfn noexport for=AbortSignal>signal abort</dfn>, given an {{AbortSignal}} object

Done.

>  </ol>
 
-<p>A <var>followingSignal</var> (an {{AbortSignal}}) is made to
-<dfn export for=AbortSignal>follow</dfn> a <var>parentSignal</var> (an {{AbortSignal}}) by running
-these steps:
+<p>To <dfn export for=AbortSignal>create a composite abort signal</dfn> from a list of

Done.

> +{{AbortSignal}} objects <var>signals</var> or a single {{AbortSignal}} <var>signal</var>, an
+optional <var>signalInterface</var>, which must be either {{AbortSignal}} or an interface that
+inherits from it, and an optional <var>realm</var>, run these steps:

That's fair - changed to requiring a list.

Regarding interface vs. creation algorithm: The main reason it has this form is to ensure the signal is newly created (i.e. not associated with a controller), since that's an assumption in the algorithm. The language ~= that of "create an event". There's another alternative where the exported algorithm just takes an optional realm and delegates to a private algorithm that takes a signal (to also be used by TaskSignal), but that's probably overkill?

I removed the default value since this likely won't have many callers callers (users of follow (i.e. fetch) and the TaskSignal specialization).

>  
- <li>
-  <p>Otherwise, <a for=AbortSignal lt=add>add the following abort steps</a> to
-  <var>parentSignal</var>:
+ <li><p>If <var>signal</var> was given, then set <var>signals</var> to a new <a for="/">list</a> and
+ <a for=list>append</a> <var>signal</var> to it.
+
+ <li><p><a for=list>For each</a> <var>signal</var> of <var>signals</var>: if <var>signal</var> is
+ [=AbortSignal/aborted=], then set <var>resultSignal</var>'s [=AbortSignal/abort reason=] to
+ <var>signal</var>'s [=AbortSignal/abort reason=] and return <var>resultSignal</var>.
+ </li>

Thanks, done.

>  
+ <li><p><a for=list>For each</a> <var>signal</var> of <var>signals</var>:

Thanks, fixed.

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

Message ID: <whatwg/dom/pull/1152/review/1288302517@github.com>