github at esdiscuss.org (2013-07-12T02:26:56.854Z)
From: David Sheets [kosmo.zb at 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!
From: David Sheets [kosmo.zb at 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!