AP2 makes laziness easy.

Mark S. Miller erights at google.com
Mon Aug 26 08:54:28 PDT 2013


I was recently asked:

(Forwarded with permission)
> I was wondering if I could get your thoughts on delaying request
execution until invocation of 'then.'
> [...] I don't always want an HttpRequest object to make a network request
on creation, because
> sometimes I merely aggregate the HttpRequest objects into a single
HttpBatch object that I can
> execute.
>
> Do you see any problems with offering an alias like this?
>
> HttpRequest.protototype.then = function(onFul, OnRej) {
>   return this.execute().then(onFul, OnRej);
> };
>
> [...] What would be the implications of this? [...]


Two things struck me about this questions:

First:

The move to AP2, where assimilation happens only on the input side of a
.then, makes thenables such as those above a perfect way to express
laziness. In current Promises/A+, where assimilation happens on the output
side of a .then, the thenable above will be "forced" too early:

// hr is the thenable intended to be lazy
hr = new HttpRequest(....);

// p1 is a genuine promise
p2 = p1.then(v => hr);

//.... much later ....

p3 = p2.then(onFul, onRej);

In current Promises/A+, hr is forced when p2 is constructed, which probably
doesn't break the code but is wasteful -- it doesn't need to be forced yet.
And if p2 never happens to be used, hr didn't need to be forced at all.

In our newfangled AP2 promises (which Promise/A+ will also be adopting), p2
merely "accepts" hr. hr.then doesn't get checked or invoked until/unless
p2.then is invoked, which is indeed as late as possible.

Second:

Since today this code will still typically work, and will in the near
future successfully become lazier, we should expect a lot of such code to
exist by the time we roll out our new standard. This brings us back to our
need to chose between "compat-duck", where thenable is simply (typeof
obj.then === 'function'), and "narrow-duck", where some additional marking
is required.

If we wish to go with narrow-duck, we need to agree on and promote that
additional marking asap, before more such code accumulates, or we need to
give up on narrow-duck. We are faced not just with the legacy of all the
existing promise libraries that would need to add this additional marking
to their promises. We are also faced with all the users of these promise
libraries who hand-roll their own thenables as above, to be assimilated by
these promise libraries.

IMO, I expect it is already too late for narrow-duck, and that we will find
we are already stuck needing to standardize compat-duck, even though it
will misinterpret some other existing non-thenable uses of "then".

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


More information about the es-discuss mailing list