<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2013/5/26 Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.com" target="_blank">brendan@mozilla.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Russell Leggett wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm sorry if I have just missed it trying to keep up to date, but what are the compelling use cases.<br>
</blockquote>
<br></div>
AsyncTable with promises as values.<br></blockquote><div><br></div><div style>What the discussion at last week's TC39 meeting clarified for me is the following:</div><div style><br></div><div style>- Promises are primarily a control-flow abstraction.</div>
<div style>- Sometimes, they are also used as a data-abstraction (i.e. as a container in their own right, wrapping an arbitrary payload).</div><div style>- All of the subtle problems discussed in these threads only start to arise when these two use cases of promises are being mixed, e.g. a promise-as-data-container being mistaken for a promise-as-control-abstraction. This rarely happens in application code, but may happen in generic library code.</div>
<div style><br></div><div style>The AsyncTable is one example of such generic library code that uses both promises-as-data and promises-for-control.</div><div style><br></div><div style>Personally, after 6 years of programming with futures/promises, I have almost never used promises-as-data. I use them exclusively for control. I suspect most proponents of the Q-style of using promises share that experience.</div>
<div style><br></div><div style>Cheers,</div><div style>Tom</div></div></div></div>