Where'd Promise#done go?

Mark S. Miller erights at google.com
Thu Jun 20 19:56:13 PDT 2013


On Thu, Jun 20, 2013 at 3:19 PM, Claus Reinke <claus.reinke at talk21.com>wrote:



> If we want to push the "lazy-evalutation" into the ... part, things get
>>>
>> more interesting, as one would need to model the data-dependencies
> and delay looking at t1p/t2p further. One could define an inline
> then-able to capture this:
>
>    x.a().then( t1p=>
>    y.b().then( t2p=>
>    let t3p = { then(cb) { t1p.then( t1=> t2p.then( t2=>
>                                        t1.c(t2).then( t3=> cb(t3) ) ) ) };
>    ...' ) )
>
> (where ...' is ..., transformed to work with a promise t3p instead of t3)
>
> Now, waiting for the .a and .b roundtrips would be delayed until
> some code in ...' actually needs to look at t3. One could further
> delay looking at t2 if t1.c() could deal with a promise t2p.
>

[colon removed from above quote per Tab's suggestion]

Ok, you've delayed sending the .c until you needed t3p. But that's the
opposite of the promise pipelining optimization! The point is not to delay
sending .c till even later. The point is to send it before the round trips
from .a or .b complete. This code still cannot do that.


>
> This additional flexibility is not available in a flat-promise design,
> which is why I think such a design is a mistake. Of course, even
> if one wants to accept the restrictions of a flat-promise design,
> the flattening should happen in promise construction, not in .then.
>
> Claus
>
>
>


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


More information about the es-discuss mailing list