Re: Concerns about DOMRequest

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.

In fact, I would prefer the following syntax over both (and it is
trivial to implement):

doSomethingAsynchronously(params).where ( {
      onsuccess: mySuccessHandler,
      onerror: myErrorHandler,
      onpartialresults: myResilientHandler,
      onmyevent1: myEventHandler1,
      onmyevent2: myEventHandler2
} );

Is there already a better way to do this?

Best regards,
Zoltan



On Mon, Feb 18, 2013 at 6:38 PM, Marcos Caceres <w3c@marcosc.com> wrote:
>
>
>
> On Monday, 18 February 2013 at 16:19, Jonas Sicking wrote:
>
>> You should look at the DOMFuture API, which is currently the closest
>> thing we have to a proposal for a standardized promise. It's just a
>> DOMRequest with a .then function as well as some bikeshed naming
>> issues ("value" instead of "result" etc).
>>
>> Keeping .result and .error separate is just good API design. Sure, we
>> could stuff any errors into the .result property, but that makes it
>> harder and more error prone for people to check if the promise
>> succeeded or failed. I.e. you'd have to look at a separate .state or
>> boolean .failed property to see if the .result contains a success or
>> error value.
>>
>> There's definitely a lack of a Q.all function. That needs to be added.
>> But it's not clear that that would go directly on the
>> DOMRequest/DOMFuture interface.
>>
>> Of course, saying that "DOMRequest is just a promise without a .then
>> function" is a bit of a simplification giving that most promise
>> libraries are literally just a .then function. That doesn't change the
>> fact that DOMRequest is a good stand-in until we have a standardized
>> promise though.
>
> Just trying to avoid lock-in when a potentially better solution exists - I just don't want to get to the point where people say "oh, we shipped… can't change it now. Sorry." If we are going to have stand-ins they should be clearly marked as such in the proposals.
>> If you are eager to see a standardized promise I
>> suggest you contribute to DOMFuture, which David Braunt has been
>> doing, or otherwise bring a promise proposal to an appropriate W3C WG.
>
> I'm keen to contribute to DOMFuture, which is why I dragged Alex and Anne into the discussion (though they've now vanished from the CC list) - so we can actually bring this to the right working groups, which right now mostly affects this one. It's also good to cover all angles of criticism that have been thrown at DOMRequest, and I appreciate you and Mounir addressing those.
>
> --
> Marcos Caceres
> http://datadriven.com.au
>
>
>
>
> ---------------------------------------------------------------------
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki
> Business Identity Code: 0357606 - 4
> Domiciled in Helsinki
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.

Received on Monday, 18 February 2013 17:43:41 UTC