Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Fri, Apr 26, 2013 at 10:03 AM, Domenic Denicola
<domenic@domenicdenicola.com> wrote:
> From: Tab Atkins Jr. [jackalmage@gmail.com]
>> The need for this will decrease now that DOM Futures exist, and libraries switch to using those (or a subclass of them) rather than rolling bespoke promises.
>
> Last I heard, jQuery has committed to never switching their promises implementation to one that works, for backward compatibility reasons. Rick might know more about if thinking has changed recently, though.

Yeah, that's fine.  jQuery's promises are super-broken anyway, so it
was unlikely they'd be able to change over to being compliant with the
rest of the ecosystem.  That's why we have explicit assimilation
functions (or, in jQuery's case, I expect them to provide a function
that converts their promise into a Future).

> Even then, it's very naive to expect all code will be upgraded to subclass a DOM API.

I hear some disdain in your text here.  Why, because it's a "DOM API"?
 Futures are only DOM because we needed it faster than TC39 could have
provided it, but the intention is that they'll migrate into the ES
spec in ES7 or so.

I *do* expect that a lot of smaller libraries which currently use
bespoke promises to upgrade into Futures or Future subclasses, simple
because they have less back-compat pressure and being auto-compatible
with the standard version is useful.  I also expect that new libraries
will just use Futures or Future subclasses.  (All of this will happen
*after* browsers actually implement Futures, of course.)

~TJ

Received on Friday, 26 April 2013 18:02:33 UTC