<div dir="ltr"><div><div class="gmail_extra">I talked a bit with Yoric on irc, and I hope this is a reasonable summary of the discussion:<br><br></div>* It's a not-uncommon pattern for an API implementor to add a then() or two to the chain to fixup return values of other functions (at least Yoric and I have both done that)<br>

</div><div><div class="gmail_extra">* Deferring these sorts of fixups to another tick is pretty wasteful.<br><div class="gmail_extra">* The problems I've been describing really apply to returning an already-resolved promise from an API entry point - synchronous resolution of then() chains seems right to me.<br>

</div><div class="gmail_extra">* Asking every consumer of a promises API to be resilient against already-resolved return values seems unreasonable to me.<br></div><div class="gmail_extra">* Asking every producer of promises to think about this by default seems unreasonable.<br>

</div><br></div><div class="gmail_extra">So it seems like Promise.defer() should (as its name implies) return a promise that can't be resolved on the same tick, and we can add a footgun to return a promise that can be resolved on the same tick.<br>
</div><div class="gmail_extra">then() would remain sync.<br><br></div><div class="gmail_extra">This moves the burden of keeping a consistent API (that isn't returning already-resolved promises) to the API producer rather than the promises library, but makes it happen by default and prevents ticking on every then().<br>
<br></div><div class="gmail_extra">-dave (who will probably stop talking about promises now).<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra"><br></div><div class="gmail_quote">
On Fri, Apr 5, 2013 at 2:26 AM, David Rajchenbach-Teller <span dir="ltr"><<a href="mailto:dteller@mozilla.com" target="_blank">dteller@mozilla.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
1. promises remain in add-on SDK, with the process outlined by Mossop;<br>
2. get Paolo's implementation of promises finished and landed, confirm<br>
that it solves the issues we have with stack explosion;<br>
3. progressively (certainly quickly) add support for debugging options;<br>
4. if we believe that developers will depend on subtleties of evaluation<br>
order, work on fuzz-testing promises;<br>
5. provide a simple wrapper to defer execution of a promise.<br>
</blockquote></div><br><br></div></div></div>