Le 09/11/2012 18:01, John J Barton a écrit :
On Fri, Nov 9, 2012 at 4:33 AM, David Bruant <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
