Le 24/04/2013 19:41, Andreas Rossberg a écrit :
On 24 April 2013 19:20, Mark S. Miller <[email protected]> wrote:
On Wed, Apr 24, 2013 at 10:14 AM, Tab Atkins Jr. <[email protected]>
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){
if(Future.isFuture(v)){
v.then(res);
}
else{
// 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.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
