Re: Concerns about DOMRequest

On Mon, Feb 18, 2013 at 8:12 PM, Marcos Caceres <w3c@marcosc.com> wrote:
> On Monday, 18 February 2013 at 17:43, Kis, Zoltan wrote:
>
>> 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
>> } );
>
> That could work, but it's just duplicating the IDL event handler attributes of the other two models, and you don't actually need .where() as it's just serving to set optional things that could be set as the call to doSomethingAsynchronously:
>
> doSomethingAsynchronously(param, {optional handlers things})

I don't have a strong opinion on this, but I would prefer something
else (even DOMRequest). The original syntactic issue was the apparent
"visual" race condition with the DOMRequest notation, we can fix that,
but I'd prefer structuring things in a similar way.

>
> IMO, it's better to keep everything more tightly bound (by using event handler IDL attributes directly on the object). It also makes it easier to inspect what is going on. If I get a promise returned from doSomethingAsynchronously (and if doSomethingAsynchronously implements EventTarget + IDL event handler attributes, like onsuccess), I want to be able to inspect those. In your model that might not always be possible. The semantics of "where" is also bit confusing, IMO - as it has SQL connotations: as in 'SELECT * WHERE some condition is met'.

Of course we could have the ".where()" function in addition to the
".then()" function (not instead of it) for the relatively rare case
when I need to customize the execution by custom event handlers or
properties. This is chainable, too, and it is equivalent to

doSomething(params).where ({
     onpartialresults: myResilientHandler,
     onmyevent1: myEventHandler1,
     onmyevent2: myEventHandler2
}).then(mySuccessHandler, myErrorHandler);

Which is very close to your version - but then I found to be more
honest using only the "where()" method. In most cases the "then()"
could be used.

As for the  "where" name, of course it could be something else, but it
since it is setting the preconditions of the asynchronous operation,
the name seemed to be logical to me.

The whole thing is quite trivial, just provides a more intuitive way
to express setting the callbacks. That said, I am fine with either
method, we just need to agree which one to use(s) in the sysapps WG.

Best regards,
Zoltan

Received on Monday, 18 February 2013 19:04:10 UTC