[Bug 24291] Add a Promise type to WebIDL, and make it not distinguishable from anything

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24291

--- Comment #7 from Tab Atkins Jr. <jackalmage@gmail.com> ---
So, discussion in the Service Worker spec-a-thon shows that this kind of
unioning is actually rather useful.  It comes with some significant
limitations, though:

1. Allowing "T or Promise<T>" is *not* just "Sync<T> or Async<T>"; it's
"Sync<T> or Async<T> or AsyncError".  The third case has to be specially
handled, and often has no precedent in the sync-handling case.

2. Taking a Promise argument significantly restricts what you can do with other
function arguments.  No other arguments can interact with the Promise'd
argument, because (due to Promise chaining, where if one async call fails you
try another one) the author may not know exactly which argument it will
eventually resolve to.  If you ever want to add such an argument, you have to
do one of the following:
  a. Bake the extra arg into the object the Promise resolves to instead.
  b. Do something hacky like allowing the argument to be "T or [T, MoreStuff]",
and letting the Promise resolve to that as well.
  c. Accept that using a Promise arg doesn't let you vary the other arg based
on the used value, and make sure your API can be called from *inside* the
promise callbacks instead if you need that.  (That is, allow inverting the
logic: in addition to "foo(myPromise)", allow "myPromise.then(foo)".)

As long as you can accept these restrictions, it should be okay to allow a "T
or Promise<T>" union.  Doing so is really helps with minimizing API surface in
at least some cases.  (In the case of Service Workers, it adds three lines of
non-obvious code to the most common, basic async-response case.  Skipping those
lines appears to work in simple cases but will fail in reasonably common corner
cases.)

I'd be fine with a strong warning that you shouldn't do so without API review
from a relevant standards body, though.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 23 January 2014 02:28:00 UTC