Re: Concerns about DOMRequest

On Monday, 18 February 2013 at 19:03, Kis, Zoltan wrote:

> On Mon, Feb 18, 2013 at 8:12 PM, Marcos Caceres <w3c@marcosc.com (mailto: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.

I don't mind so much as long as "then()" is there and that the callbacks give you the result as an argument. That gets rid of most of my gripes with the design as it means that I can create the success/error functions before I invoke the async operation, and then call "foo().then(success,error)".
> > 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 point I was trying to make is that "where" is implied as a setter operation (for all the onwhatvers). What I mean is that where is only sugar for:

doSomething(params, {onpartialresults: ...});  

//which is just much needed sugar for
var x = doSomething(params)
x.onpartialresults = function(){}

//But not really practical substitute for:
x = doSomething();
x.addEventListener("partialresults", listener1);

x.addEventListener("partialresults", listener2);


//Although that can still be handled with:
doSomething().where(onpartialresults: function(data){ listener1(data); listener2(data);})

The question I have is, is there a case for continuously replacing out the event handlers after each .then() with .where()?:

doSomething().where(...).then(…).where(...).then(…)?

I guess there might be.  
> The whole thing is quite trivial, just provides a more intuitive way
> to express setting the callbacks.

Sure, I can see that. But it's about as verbose as:
   
var thing = new SomeDoer();  
thing.onmyevent1 = function(){};
thing.onmyevent2 = function(){};
thing.addEventListener("myevent", function(){});

thing.addEventListener("done", function(){});

thing.doIt();

But just not chainable.  
> That said, I am fine with either
> method, we just need to agree which one to use(s) in the sysapps WG.

Or across the whole Web platform where appropriate :) That's what we are trying to get to ATM. Anyway, I think there are good ideas flying around everywhere. It will be great for us all to sit down and hash something good out.

Received on Tuesday, 19 February 2013 09:45:18 UTC