A Challenge Problem for Promise Designers

David Bruant bruant.d at gmail.com
Fri Apr 26 06:36:57 PDT 2013


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


More information about the es-discuss mailing list