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

Re: Deprecating Future's .then()

From: Sean Hogan <shogun70@westnet.com.au>
Date: Thu, 06 Jun 2013 11:12:43 +1000
Message-ID: <51AFE20B.60509@westnet.com.au>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: Anne van Kesteren <annevk@annevk.nl>, Sam Tobin-Hochstadt <samth@ccs.neu.edu>, "Mark S. Miller" <erights@google.com>, "www-dom@w3.org" <www-dom@w3.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Alex Russell <slightlyoff@google.com>
On 6/06/13 10:56 AM, Tab Atkins Jr. wrote:
> On Thu, Jun 6, 2013 at 9:51 AM, Sean Hogan <shogun70@westnet.com.au> wrote:
>> Should the spec continue to allow this behavior?
>>
>> or ...
>>
>> Should the resolve algorithm - which is currently infinite unwrap for
>> accepted / fulfilled futures - also be infinite unwrap for rejected futures?
> I'm satisfied with either behavior.  It might be nice to have it
> mirror the then/chain behavior, where it fully-unwraps or
> single-unwraps as appropriate, but I'd likely be fine with both doing
> single-unwrapping or both doing full-unwrapping.
>
> ~TJ
>

I think the most contentious behavior would be what to do with mixed 
sequences of accepted / rejected Futures.

Should

     Future.accept( Future.reject ( Future.accept( true ) ) )
     .then( function(val) { console.log( val ); } , function(err) { 
console.error( err ); });

behave the same as

     Future.reject( Future.accept( Future.reject ( Future.accept( true ) 
) ) )
     .then( function(val) { console.log( val ); } , function(err) { 
console.error( err ); });


Is it just a nonsense usage - most likely to be a programming error?
If so, what is the best / noisiest way to fail?
Received on Thursday, 6 June 2013 01:13:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC