- From: David Bruant <bruant.d@gmail.com>
- Date: Tue, 19 Feb 2013 23:21:04 +0100
- To: "Kis, Zoltan" <zoltan.kis@intel.com>
- CC: Marcos Caceres <w3c@marcosc.com>, Jonas Sicking <jonas@sicking.cc>, Kenneth Rohde Christiansen <kenneth.r.christiansen@intel.com>, Mounir Lamouri <mounir@lamouri.fr>, public-sysapps@w3.org
Le 18/02/2013 18:43, Kis, Zoltan a écrit :
> Hello,
>
> I would not like to confuse the discussion (and myself :) even more,
> but possibly there are more than only success and error cases to
> handle.
>
> It seems to me that the "plain old" DOMRequest is quite consistent in writing:
> {
> var req = doSomethingAsynchronously(params);
> req.onsuccess = mySuccessHandler;
> req.onerror = myErrorHandler;
> req.ontimeout = myEventHandler1;
> req.onmyevent = nyEventHandler2;
> }
>
> I am not sure this would be expressed simpler and more straightforward
> with DOMFuture.
The following extension mechanisms to DOMFuture can be used:
1) Sending a specific success/error value type. For instance, timeout
could just be rejecting with "new TimeoutError()" as value.
The current proposal includes syntactic sugar to send some specific
error types objects like "AbortError" and "TimeoutError" (I'm not sure
if these errors are sketched yet, but that's more a detail at this point)
The idea here is that there are only 2 channels to a Future,
success/failure and different types of failures all go through the
failure channel, but can be differentiated with different values, very
much like throwing different values.
2) Subclassing DOMFuture
Like the ProgressFuture [2]:
interface ProgressFuture : DOMFuture{...}
I think it's good to have a very simple DOMFuture, and that other specs
only use these 2 mechanisms to expand on DOMFuture. Specifically, I
think it'd be of bad taste to define a partialInterface to expand DOMFuture.
David
[1] https://github.com/slightlyoff/DOMFuture/blob/master/ProgressFuture.idl
Received on Tuesday, 19 February 2013 22:21:35 UTC