<div dir="ltr">Yep I agree with this, let's move forwards!<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 5, 2013 at 9:32 AM, Gavin Sharp <span dir="ltr"><<a href="mailto:gavin@gavinsharp.com" target="_blank">gavin@gavinsharp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't think I quite agree with your characterization of "the only<br>
reason", but I don't have any objections to your plan of action. I<br>
think item 5 is important, which I think matches with Dave's latest<br>
suggestion as well.<br>
<br>
I think we've discussed this enough, so let's focus on completing<br>
items 2, 3 and 5 in your list.<br>
<span class="HOEnZb"><font color="#888888"><br>
Gavin<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Fri, Apr 5, 2013 at 2:26 AM, David Rajchenbach-Teller<br>
<<a href="mailto:dteller@mozilla.com">dteller@mozilla.com</a>> wrote:<br>
> As project Async & Responsive (tba) will largely depend on promises, I<br>
> would like to try and wrap this up quickly.<br>
><br>
> So far, it looks like the only reason for adopting *deferred* execution<br>
> that was actually defended is that, in simple cases (arguably race<br>
> conditions), their behavior is easier to predict syntactically. As far<br>
> as I am concerned, there is no good reason to rely on a specific<br>
> resolution of race conditions – doubly so since Task.js makes it trivial<br>
> to avoid the race conditions in all the meaningful cases that I can<br>
> imagine. As pointed out half-jokingly by Gps, we can even introduce<br>
> fuzz-testing to root out some race conditions. That might actually be<br>
> simple.<br>
><br>
> So, here is my proposal:<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>
><br>
> Best regards,<br>
>  David<br>
><br>
> --<br>
> David Rajchenbach-Teller, PhD<br>
>  Performance Team, Mozilla<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> firefox-dev mailing list<br>
> <a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
</div></div></blockquote></div><br></div>