<div dir="ltr"><div><div><div><div><div>I think the problem some people have with non-deferred-promises is that given the following code:<br>---<br></div>foo().then( ){<br></div>  dump("1");<br></div><div>  return nextTickPromise();<br>
</div>}).then(function() {<br></div><div>  dump("2");<br></div>});<br><br></div><div>dump("3");<br></div><div>---<br></div><div><br></div><div>Whether you get "123" or "312" depends on the implementation of foo().  And if it's sync today, you have no guarantee that it will stay that way (like mconnor said - if you had such a guarantee you wouldn't be using promises).  With async promises you can guarantee that order will be 321.<br>
<br></div><div>Unless every consumer of your library is careful, that's going to be error prone and hard to test.  The important thing here is that the bugs are going to happen because *users* of foo() aren't careful, not because the *implementor* of foo isn't careful.  So whether foo() can choose to use defer() or syncDefer() doesn't really help anything.<br>
<br></div><div>So we basically need to ask if we expect everyone to be able to carefully write their code to handle 312 vs. 123 safe every time (probably without testing, because I unless we mock every promise-returning function to provide a sync vs. async problem the testing will be insufficient).  I don't think we can.<br>
<br></div><div>I'd say we should defer the decision of whether the caller is going to be careful enough to the caller, not the callee.  The above snippet should print 321 by default, no matter how foo() is implemented, but if I'm gutsy enough to take that ambiguity into my hands I can do;<br>
<br>foo().sync().then() {<br>}<br></div><div>... etc.<br><br></div><div>-dave<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 4, 2013 at 11:35 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Let's fix some vocabulary.<br>
<br>
Asynchronous === "I don't know when the call will complete"<br>
Deferred === "The call will not complete on this tick"<br>
<br>
Promises are invaluable in presence of asynchronicity. However, this<br>
does not mean that we need to defer every single evaluation, nor does<br>
this mean that promises themselves should enforce deferred evaluation.<br>
<br>
For instance, the implementation of OS.File:<br>
- defers most I/O to a worker;<br>
- chains promises without deferring any further to add error handling,<br>
resource cleanup, present the result, etc.<br>
<br>
Cheers,<br>
 David<br>
<div class="im HOEnZb"><br>
On 4/4/13 8:11 PM, Mike Connor wrote:<br>
> This is sort of the meta-question around promises.  What are we using<br>
> them for, and why?  My understanding is that promises are useful<br>
> precisely because they can be chained like sync calls, while<br>
> being/enabling async work.  I'm not sure what the value proposition is<br>
> for promises if resolution is always immediate, why not use return/throw<br>
> like normal JS in that case?<br>
><br>
> -- Mike<br>
<br>
<br>
</div><div class="im HOEnZb">--<br>
David Rajchenbach-Teller, PhD<br>
 Performance Team, Mozilla<br>
</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>