W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: A Challenge Problem for Promise Designers

From: David Bruant <bruant.d@gmail.com>
Date: Fri, 26 Apr 2013 15:36:57 +0200
Message-ID: <517A82F9.8060403@gmail.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC