Re: Concerns about DOMRequest

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})

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'.

Received on Monday, 18 February 2013 18:12:42 UTC