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: Domenic Denicola <domenic@domenicdenicola.com>
Date: Fri, 26 Apr 2013 15:03:56 +0000
To: David Sheets <kosmo.zb@gmail.com>
CC: Juan Ignacio Dopazo <dopazo.juan@gmail.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F7EF5C0F2@BY2PRD0510MB354.namprd05.prod.outlook.com>
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

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