Promises

Mark S. Miller erights at google.com
Fri Nov 9 09:35:39 PST 2012


On Fri, Nov 9, 2012 at 9:01 AM, John J Barton
<johnjbarton at johnjbarton.com>wrote:

>
>
>
> On Fri, Nov 9, 2012 at 4:33 AM, David Bruant <bruant.d at gmail.com> wrote:
>
>> Hi,
>>
>> In this message, I'll be sharing some experience I've had with the Q
>> library. I have worked with it for about 7-8 months in a medium/big Node.js
>> application (closed source, so I can't link, sorry).
>> I'll be covering only the parts that I have used during this experience.
>> It's related to my own writing style and I don't mean that the rest is
>> useless and should be thrown away, but the subset I'll be covering here has
>> proven to be sufficient to my needs for several months.
>>
>> I would be interested if others could share their experience if they had
>> a different way of using promises.
>>
>
> I also used Q (a slightly older version) for several months before
> removing it because of cost/benefit.
>

I would like to understand this better. When you using only the .then/.when
callback style, or were you using the .send/.post style to send eventual
messages to the promised object? In my own code, I use mostly the
.send/.post style, and I find it substantially improves readability.

See <https://docs.google.com/file/d/0Bw0VXJKBgYPMU1gzQ3hkY0Vrbmc/edit>
(with improved slides at <
http://code.google.com/p/es-lab/downloads/detail?name=friam.pdf#makechanges>)
for a particularly elegant example using promises. I would be curious how
well you could express this without promises.



>
>
>>
>> # 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.
>
>
>>
>> ## A Q Promise is a {then, fail} object.
>> Given the previous code, it's possible to do:
>>
>>     var someData1P = query(q1);
>>     someData1P.then(function(data)**{
>>         // do something with data
>>     });
>>     someData1P.fail(function(**error){
>>         // handle the error
>>     });
>>
>> Both then and fail return another promise for the result of the callback
>>
>
> Note these callbacks: promise based code is very callback-y.
>
>  ....
>
>>
>>
>> ## Q.all
>> My favorite feature is the Q.all function. Q.all accepts an array of
>> promises and returns a promise which will be fulfilled when all promises
>> are.
>
> ...
>
>
>
>> I used this extensively and it's been extremely helpful. Personally, to
>> synchronize different async operations, I've never read code more elegant
>> than what Q.all offers. I'm interested in hearing what other's experience
>> is on that point.
>>
>
> I agree that this is the most valuable feature and the one that got me to
> try Q and stick with it for a while. However, in my experience  this
> feature is only needed a few times in an application.
>
>
>>
>> # 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.
>
>
>> I think I've shared pretty much all my experience and thoughts on the
>> topic. I feel that overall, the Q API is really good to work with promises
>> and my opinion is that a standard promise feature should have the same
>> features (I however don't care about the exact names of methods).
>
>
> I agree that Q is exceptionally well done, so much so that I came away
> much less enthusiastic about the promise concept overall.
>
> jjb
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121109/99e73082/attachment.html>


More information about the es-discuss mailing list