<div dir="ltr"><div>I was recently asked: </div><div><br></div><div>(Forwarded with permission)</div>> I was wondering if I could get your thoughts on delaying request execution until invocation of 'then.'<br><div class="gmail_quote">
<div dir="ltr"><div>

<div>> [...] I don't always want an HttpRequest object to make a network request on creation, because </div><div>> sometimes I merely aggregate the HttpRequest objects into a single HttpBatch object that I can </div>
<div>> execute.</div>

<div>> </div><div>> Do you see any problems with offering an alias like this?</div><div>></div><div>> HttpRequest.protototype.then = function(onFul, OnRej) {</div><div>>   return this.execute().then(onFul, OnRej);</div>
<div>> };</div><div>></div></div><div>> [...] What would be the implications of this? [...]<br></div><div><br></div><div><br></div><div>Two things struck me about this questions:</div><div><br></div><div>First:</div>
<div><br></div><div>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:</div>
<div><br></div><div>// hr is the thenable intended to be lazy</div><div>hr = new HttpRequest(....);</div><div><br></div><div>// p1 is a genuine promise</div><div>p2 = p1.then(v => hr);</div><div><br></div><div>//.... much later ....</div>
<div><br></div><div>p3 = p2.then(onFul, onRej);</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Second:</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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".</div>
<div><br></div></div></div>-- <br>    Cheers,<br>    --MarkM
</div>