- From: David Bruant <bruant.d@gmail.com>
- Date: Fri, 26 Apr 2013 15:36:57 +0200
- To: Kevin Smith <zenparsing@gmail.com>
- CC: Andreas Rossberg <rossberg@google.com>, "Mark S. Miller" <erights@google.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Mark Miller <erights@gmail.com>, Dean Tribble <tribble@e-dean.com>, es-discuss <es-discuss@mozilla.org>
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
Received on Friday, 26 April 2013 13:37:27 UTC