David Bruant bruant.d at gmail.com
Thu Apr 25 02:22:13 PDT 2013

Le 24/04/2013 19:41, Andreas Rossberg a écrit :
> On 24 April 2013 19:20, Mark S. Miller <erights at google.com> wrote:
>> On Wed, Apr 24, 2013 at 10:14 AM, Tab Atkins Jr. <jackalmage at gmail.com>
>> wrote:
>>> Q and similar libraries don't actually assume that a Future<Future<x>>
>>> is a Future<x>.
>> Yes it does. Except of course that we call these "promises". Please see the
>> extensive discussions on the Promises/A+ site about why this flattening
>> behavior is important.
> That strikes me as a very odd design decision, since it would seem to
> violate all sorts of structural and equational invariants.
 From a developer perspective, my experience using promises is that it's 
an extremely convenient property. Basically, if you can only have x and 
Future<x>, but never Future<Future<x>>, you never have to worry about 
the resolved value. You know it's always a non-Future value. And that's 
what you want. When you call 
getQueryResult(query).then(function(result){...}), you always want 
result to be something you can play with, not a promise. Unless you're 
writing the promise infrastructure, you don't want to have to worry 
about that.

If Future<Future<x>> can exist, then you'll have to write this 
boilerplate code in a lot of places:
     f.then(function res(v){
             // actual work with the resolved value.

The promise library taking care of this boilerplate for you is a good 
property in my opinion. It also helps making chaining more usable and 
ease refactoring:

     var p2 = p.then(function(x){
         return somethingWith(x);

Whether somethingWith(x) returns a promise or non-promise value, you 
know that in p2.then(), you'll be dealing with a non-promise value. If, 
for whatever reason, you change somethingWith(x); to return a promise 
instead of a non-promise (or vice-versa), none of your code (beyond the 
somethingWith body) needs to be changed (assuming, you're only returning 
the value as it's the case here).
I've had only once to change the signature of a function from a 
non-promise to a promise and that property was really useful.

As soon as you have a decent code base with a lot of functions returning 
and playing with promises, it's nice to not have to worry about "a 
promise for a promise" and have the promise infrastructure doing the 
flattening work for you.


More information about the es-discuss mailing list