Promises

David Bruant bruant.d at gmail.com
Tue Nov 13 06:33:59 PST 2012


Le 11/11/2012 14:44, Kevin Smith a écrit :
>
>     Is the following a counter-example?
>
>     On Fri, Nov 9, 2012 at 8:33 AM, Mark S. Miller <erights at google.com
>     <mailto:erights at google.com>> wrote:
>
>         Hi David, thanks for your thoughtful post. I've always used
>         the two-arg form of .then[1], but your post makes a strong
>         case for more often using separate one-arg .then and .fail
>         calls. I say only "more often" because the two arg form can
>         easily make distinctions that the one-arg forms cannot
>
>         var p2 = Q(p1).then(val => { throw foo(val); },
>                           reason => { return bar(reason); });
>
>         is different than either of the one-arg chainings.
>
>
> I don't think so.  Consider the general two-arg form:
>
>     promise.then(onSuccess, onFail);
>
> We can transform that into a one-arg form like so:
>
>     function WrappedError(err) {
>         this.error = err;
>     }
>     promise
>     .fail(err => new WrappedError(err))
>     .then(val => val instanceof WrappedError ? onFail(val.error) : 
> onSuccess(val));
>
> But this involves the creation of an extra (unnecessary) node in the 
> graph.
I agree. But I feel it's possible for engines to optimize (both in time 
and memory) by detecting the .then(func).fail() (or the other way 
around) pattern.
Also, assuming async programming is related to DB query/disk 
access/network I think these costs are negligible when compared with the 
time to wait for network or a user input or a timeout.

> And it's obtuse.  I still think the two-arg form makes the most sense 
> as a base-level "then" API.
If the second argument is optional, it's possible to have both one-arg 
and two-arg styles in the same API.
What do people think about this idea?

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


More information about the es-discuss mailing list