ForbesLindesay

Arguments in favor of Promises for Promises

The argument in favor of Promises for Promises is structured as follows:

1. Examples
2. Lazy Promises
3. Remote Promises
4. Partial Results
5. Error Handling
6. Testing

ForbesLindesay

Arguments Against Promises for Promises

The argument for avoiding promises for promises is fairly simple. A promise is a representation of a value that will exit in the future. If that value is still a promise, you haven't really got to the final value yet. Conceptually having the promise doesn't really provide anything other than a means to obtain the final value, as such it's of no additional use to be able to get the intermediate nested promises: You might as well just jump straight to the value.

The "JQPFAQPFAWJPFADFFAN" Problem

This problem is explained in more detail by @erights here. The currently proposed [[Resolve]] algorithm only dictates this recursive flattening for unrecognised thenables, not for promises. THe advantage of this behavior is that a user can pick up a Promises/A+ library and return a deeply nested mess of foreign promises objects (all of which were broken enough not to do any unwrappi