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

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