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

From: David Sheets [kosmo.zb@gmail.com]

> Why is there a semantic distinction between my thenables and your thenables?

Because your thenables are not to be trusted! They could do pathological things like jQuery, or conceptually incoherent things like thenables-for-thenables. Sanitation at the boundary is the idea behind the resolve algorithm.

> If someone is using nested thenables, presumably they have a good reason. Promises/A+ acknowledges this possibility by allowing own-promises to nest.

Yes, but more importantly, it preserves the guarantees within a single library---whether they be allowing promises-for-thenables, or disallowing them. Q, when, RSVP, and others guarantee no promises-for-thenables. That is a great feature for consumers of those libraries, as has been emphasized many times in this thread (especially elegantly, I think, by David Bruant). If there were no recursive foreign thenable assimilation, then promises-for-thenables could sneak into Q/when/RSVP promise systems, breaking the assumptions of consumers of those promises.

> If we are interesting in constructing the "most standard" promises system, surely this system must grant other, foreign systems the same possibility of nesting own-promises without interference?

No. Generally, foreign systems *must* be normalized, for security concerns if nothing else. Trying to accommodate foreign system semantics into your own promise system is a recipe for disaster. Mark can expand upon this more in detail, if you think it's an important point.

> 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();
>        });
>    });
> });
> ```

> If Q, as a proper Promises/A+ library, does recursive `[[Resolve]]`, this is a promise for undefined that will be rejected with the appropriate error if any of the operations failed. But if it did one-level unwrapping, this would be a QPFAUDPFAQPFU, and it would always fulfill---failure information would have to be manually extracted.

Hope that helps!

Received on Friday, 26 April 2013 15:04:29 UTC