W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Futures

From: Dean Landolt <dean@deanlandolt.com>
Date: Mon, 22 Apr 2013 13:42:35 -0400
Message-ID: <CAPm8pjpvJptLadPugaeRyjqAFxkWVKtXCcM_1y0Eavum4UtRNA@mail.gmail.com>
To: Kevin Smith <zenparsing@gmail.com>
Cc: Domenic Denicola <domenic@domenicdenicola.com>, Brendan Eich <brendan@mozilla.com>, "Mark S. Miller" <erights@google.com>, Douglas Crockford <douglas@crockford.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Norbert Lindenberg <w3@norbertlindenberg.com>, Markus Lanthaler <markus.lanthaler@gmx.net>, es-discuss <es-discuss@mozilla.org>
On Mon, Apr 22, 2013 at 12:47 PM, Kevin Smith <zenparsing@gmail.com> wrote:

>  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 :-/
> 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?

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?

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.
Received on Monday, 22 April 2013 17:43:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:12 UTC