Le 26/04/2013 14:54, Kevin Smith a écrit :
What exactly is the controversy here?
I think we all agree with the semantics of "then" as specified in
Promises/A+. (If not, then we have a really big problem!)
If so, then the only real controversy is whether or not the API allows
one to create a promise whose eventual value is itself a promise. Q
does not: it provides only "resolve" and "reject". DOM Futures do by
way of "Future.accept". As far as I know, there's nothing about Q's
implementation that would make such a function impossible, it just
does not provide one.
I believe at this point the question isn't so much "can I build a
promise for a promise?", but rather "what should be the default Future
semantics?"
Namely:
Future.accept(5)
.then(function(x){
return Future.accept(x);
})
.then(function(y){
// is y a Future?
})
I'm arguing in favor of y being guaranteed to be a non-Future value. It
is my understanding others would want y to be a Future.
That would be the controversy as I understand it.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
