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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 26 Apr 2013 10:00:34 -0700
Message-ID: <CAAWBYDBS0CLNmTMPNFtGNmAeWnciTHRHLfsw7ugCdvic5p47CQ@mail.gmail.com>
To: David Sheets <kosmo.zb@gmail.com>
Cc: Domenic Denicola <domenic@domenicdenicola.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
On Fri, Apr 26, 2013 at 8:45 AM, David Sheets <kosmo.zb@gmail.com> wrote:
>>> Could you point me to some code that needs dynamic flattening?
>>
>> From https://github.com/promises-aplus/promises-spec/issues/101#issuecomment-16657518
>>
>>> ```js
>>> var promise = getDataFromServerUsingQ().then(function (data) {
>>>    return $('.foo').animate('opacity', data.opacityLevel).promise().then(function () {
>>>        return updateBackboneModelViaSomeThirdPartyLibraryUsingUnderscoreDeferred().then(function () {
>>>            return tellServerThatTheUpdateSucceededUsingQ();
>>>        });
>>>    });
>>> });
>>> ```
>
> This looks like a case for static resolution to me. Like this:
>
> ```js
> var promise = getDataFromServerUsingQ().then(function (data) {
>    return Q($('.foo').animate('opacity',
> data.opacityLevel).promise()).then(function () {
>        return Q(updateBackboneModelViaSomeThirdPartyLibraryUsingUnderscoreDeferred()).then(function
> () {
>            return tellServerThatTheUpdateSucceededUsingQ();
>        });
>    });
> });
> ```
>
> I favor this expression because it *explicitly* invokes Q's behavior
> early and every use of 'then' is Q's 'then'. It costs 6 more bytes. Do
> you have any examples where you *don't know* until runtime how many
> thenables are wrapped?

Agreed.  This is just an example of the
libraries-with-mutually-unrecognizable-promises problem, which is a
very specific issue with only a weak connection to the wider
recursive-resolve problem.  As I've argued before, and David is
arguing here, the correct response to this problem is to have an
explicit assimilation operation for converting foreign promises into
your preferred version, and just sprinkling that around as necessary
when crossing library boundaries.

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.

~TJ
Received on Friday, 26 April 2013 17:01:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC