Re: Concerns about DOMRequest

Le 20/02/2013 16:48, Jonas Sicking a écrit :
>
> On Feb 20, 2013 12:15 AM, "David Bruant" <bruant.d@gmail.com 
> <mailto:bruant.d@gmail.com>> wrote:
> >
> > Le 20/02/2013 02:06, Jonas Sicking a écrit :
> >
> >> On Tue, Feb 19, 2013 at 2:07 PM, David Bruant <bruant.d@gmail.com 
> <mailto:bruant.d@gmail.com>> wrote:
> >>>
> >>> Le 18/02/2013 16:35, Mounir Lamouri a écrit :
> >>>
> >>>> On 18/02/13 15:15, Marcos Caceres wrote:
> >>>>>
> >>>>> On Monday, 18 February 2013 at 09:50, Kenneth Rohde Christiansen 
> wrote:
> >>>>>
> >>>>>> Hi there,
> >>>>>>
> >>>>>>> Examples Jonas showed using DOMFuture could just work with 
> DOMRequest
> >>>>>>> if
> >>>>>>> we add this .then() method.
> >>>>>>>
> >>>>>>> Also, we could imagine stuff like:
> >>>>>>> getSomeData().then(function(data) {
> >>>>>>> return getDataRelatedToThoseData(data);
> >>>>>>> }).then(function(data) {
> >>>>>>> show(data);
> >>>>>>> });
> >>>>>>>
> >>>>>>> I have a patch for Gecko implementing that.
> >>>>>>
> >>>>>> I like this pattern. It also seems closer to what MS are using in
> >>>>>> their Windows 8 JS APIs.
> >>>>>
> >>>>>
> >>>>> Not that just adding .then() does not address other issues with 
> the API.
> >>>>> David Braunt articulated this best in [1]:
> >>>>>
> >>>>> "In my opinion, one of the most absurd example is the DOMRequest 
> thing
> >>>>> which
> >>>>> looks like:
> >>>>> {
> >>>>> readonly attribute DOMString readyState; // "processing" or "done"
> >>>>> readonly attribute DOMError? error;
> >>>>> attribute EventListener onsuccess;
> >>>>> attribute EventListener onerror;
> >>>>> attribute readonly any? result;
> >>>>> };
> >>>>>
> >>>>> Read it carefully and you'll realize this is actually a 
> promise... but
> >>>>> it has this absurd thing that it has to have both an error and 
> result
> >>>>> field while only one is actually field at any given point.
> >>>>
> >>>> FWIW, DOMFuture has .value and .error too.
> >>>>
> >>>> Anyway, it's quite not clear why having .{value,result} and 
> .error is a
> >>>> bad thing. If the DOMRequest is used as a promise, it's unlikely 
> those
> >>>> fields would be used anyway. If those fields have to be used (ie. 
> if a
> >>>> consumer wants to access the result outside of a .then(), .done() or
> >>>> promise-like methods)
> >>>
> >>> <digression>
> >>> We can wonder whether this (need to access the value outside
> >>> then/catch/done) ever happens. I have never had the need in a 8 months
> >>> experience.
> >>> I don't think I've seen a context in Gaia where that was the case 
> either
> >>> (where a value was needed outside the context of an 
> onsuccess/onerror).
> >>> Likewise for the state attribute, to be fully honest. I'm 
> interested if
> >>> others have different experience to share on this point, though.
> >>>
> >>> Recently, the best definition I have come up with for promises was 
> [1]:
> >>> "a promise is an event emitter of a unique "success" xor "error" 
> event.
> >>> .then/.fail replace addEventListener/on".
> >>> This follows a set of reflections of the idea that objects 
> shouldn't be
> >>> thought as "properties+methods", but rather 
> "properties+methods+events" and
> >>> some recurrent idioms (like promises and streams) are nothing but
> >>> abstractions built on top of events.
> >>> </digression>
> >>>
> >>> I haven't brought up this concern about the properties, because I 
> feel it's
> >>> a minor one. My personal short-term goal is to help have 
> Future/Promise as
> >>> soon as possible built in the platform whether they fit my own 
> vision or
> >>> not.
> >>>
> >>> I'm repeating what I've said elsewhere, but what we need for 
> Futures to be
> >>> helpful:
> >>> 1) chainable .then
> >>> 2) (~optionally, but excellent for readability in some cases) 
> chainable
> >>> .fail/catch
> >>> 3) .done to end the chain (and have the devtools report uncaught 
> errors at
> >>> the end of the chain)
> >>> 4) A combining mechanism à la Q.all
> >>> This one could be optional and added as a library, but I fear 
> people will
> >>> just mess up their libraries with off-by-one errors, etc., so it'd 
> be better
> >>> to have it built-in.
> >>> 5) the consumer of a promise can't resolve it
> >>>
> >>> Besides these 5 points, I personally won't fight over anything 
> really hard.
> >>> The .result/.error properties are beyond these 5 points. The name
> >>> Future/Promise is also beyond these 5 points :-p
> >>
> >> This sounds like excellent feedback into the DOMFuture work. I
> >> personally agree with all of it except number 3. That seems like a
> >> nice-to-have to me.
> >
> > I really insist on this one.
> > One particularly annoying aspects of async programming is that you 
> have no stack trace you don't handle an error.
> >
> > f.then(function(){
> >
> >     })
> >     .then(function(){
> >         // an error is thrown here by library code and you didn't 
> expect it
> >     })
> >     .then(function(){
> >
> >     }).done()
> >
> > Without done, the unexpected error remains silent, your program 
> doesn't work, you have no idea why. When doing async testing, it often 
> means one of your async test just timeouts, which isn't very helpful.
> > I just came across this yesterday on a Node project. Working with a 
> colleague, trying to pin down an issue, I sent him the stack trace, 
> and he just answered "useless, as usual", because that's really the 
> experience of async debugging. Promises/futures offer some hope.
> > With done, you can be told an unhandled error happened. The Q 
> library throws the unhandled error (which no one really catches, 
> because the error is thrown in its own event loop turn), but that's a 
> library. With native futures, the devtools can log the error and 
> that's largely enough.
> > Additionally, with native support for DOMFuture, the devtools can 
> know exactly where the future comes from and can tell us which future 
> was the first one to be broken and provide the full list of all 
> futures involved (like a stack trace... let's call that a future 
> trace?). Super helpful.
> >
> > When you use a future every once in a while, .done is a nice to 
> have. If you use chained futures extensively all over your code, .done 
> really makes a difference.
>
> Sounds like you should file an issue on DOMDuture because this is not 
> how it currently works.
>
I assume you're referring to .done (tell me if that's not the case).

I read [1]:
     void done(optional AnyCallback onaccept, optional AnyCallback 
onreject);
So the .done method provides a last option to handle yet-unhandled 
errors and mostly importantly, it doesn't return anything meaning it has 
no other future to propagate an unhandle error to.
So if no onreject callback is passed, devtools can consider an unhandled 
error as... well... unhandled and log it... And hopefully, the future 
chain was recorded in the background, so more than just the error, it's 
possible to know where the error comes from and what its "path" was.

Also [2]:
// What is clear is that no matter what approach is pursued, integration
// with developer tooling is key. Developer consoles SHOULD log un-caught
// errors from future chains. That is to say, if future.done(onresponse); is
// the only handler given for a resolver which is eventually rejected,
// developer tools should log the unhandled error.

Integration with devtools shouldn't be part of the spec per se. However, 
the feature is designed with devtools integration in mind and from what 
I read, I feel it all describes what I expect from .done and the 
potential devtool integration.
What makes you feel there is a mismatch between the proposed DOMFuture 
and what I described?

David

[1] 
https://github.com/slightlyoff/DOMFuture/blob/0a48424390229ddca6b5cdad10d414a400eb7d0c/DOMFuture.idl#L303
[2] 
https://github.com/slightlyoff/DOMFuture/blob/0a48424390229ddca6b5cdad10d414a400eb7d0c/DOMFuture.idl#L230-L234