<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 22, 2013 at 12:47 PM, Kevin Smith <span dir="ltr"><<a href="mailto:zenparsing@gmail.com" target="_blank">zenparsing@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>FWIW I disagree with him -- I strongly suspect that by the time this were to all go down and a stable polyfill existed there'd already be too much then-demanding code in the wild. There probably already is. And at that point it's __proto__ all over again -- the standard will have no choice but to respect then and the problem cannot be fixed :-/<br>




</div></div><br></div></div></blockquote><div><br></div></div><div>Why not?  If the `then` symbol is well-known (e.g. easily imported from somewhere), then why can't libraries be upgraded to use it as an alias for their `then` method?</div>

</div></div></div></blockquote><div><br><br></div><div>I would love to see this, but best I can tell it can't be a straitforward polyfill. The necessary infrastructure has to settle, and what are Promises/A+ implementers supposed to do in the meantime?<br>

<br>Unless a reasonably elegant solution can be found I suspect any es promises proposal will include support for thenables. I spent a lot of time thinking about it a few years back and couldn't find one, so I remain skeptical.<br>

</div></div></div></div>