Promises

David Bruant bruant.d at gmail.com
Tue Nov 13 02:35:13 PST 2012


Le 09/11/2012 18:01, John J Barton a écrit :
>
> On Fri, Nov 9, 2012 at 4:33 AM, David Bruant <bruant.d at gmail.com 
> <mailto:bruant.d at gmail.com>> wrote:
>
>
>     # the Q API
>     ## A Q Deferred is a {promise, reject, resolve} object. Only the
>     deferred holder can resolve the promise (and not the promise
>     holder), addressing the security issue that's been raised on the list.
>     You create a Deferred instance by calling Q.defer()
>
>     Typically, when trying to promise-ify async APIs, you end up doing
>     something like (and that's probably also how things are done
>     internally):
>
>         function query(myQuery){
>             var def = Q.defer();
>
>             db.query(myQuery, function(err, data){
>                 if(err)
>                     def.reject(err)
>                 else
>                     def.resolve(data)
>             })
>
>             return def.promise;
>         }
>
> I had lots of code like that.
I did too. If a library has a callback style, this boilerplate is 
necessary, but if a library naturally has promises, it's fine.
The good news is that with only a bit of boilerplate code, one can work 
with one or the other style. Things would be better, but could also be 
much worse.

>
>     # Debugging
>     It's been said in other messages, one part where Q promises fell
>     short was debugging.
>
>     ...
>
>
> I suppose if we stick to console logging I could agree with this very 
> rosy description. But Q makes breakpoint debugging essentially 
> useless: the call stack is gone and you have to break much more often 
> then try to correlate the values across breakpoints.
True. You mentioned it in your last response, but built-in promises 
debugging would be of great help, because it has knowledge of the 
promise chain and could enable stepping from one resolution function to 
another resolution function.
Note that it would be impossible or close to impossible to have such a 
feature with DOMRequest (since they do not form a chain)

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121113/e3534f7f/attachment.html>


More information about the es-discuss mailing list