On Wed, Jun 5, 2013 at 6:12 PM, Sean Hogan <shogun70@westnet.com.au> wrote: > 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 ) ) ) > Answering for the Q perspective, the above expression would be written Q(Q.reject(Q(true))) Which is a broken promise whose reason for breakage is a promise for true, i.e., equivalent to Q.reject(Q(true)) We could say this is a promise whose eventual reason for breakage is "true". Of course, you said .accept/.fulfill rather than .resolve, so it means something else to .chain, but I'm speaking only for Q here. > .then( function(val) { console.log( val ); } , function(err) { > console.error( err ); }); > Since you wrote .then, this must invoke the second callback with err bound to the promise for true. > > behave the same as > > Future.reject( Future.accept( Future.reject ( Future.accept( true ) ) > ) ) > >From Q's perspective, this is Q.reject(Q(Q.reject(Q(true)))) which is equivalent to Q.reject(Q.reject(Q(true))) This is a completely different beast. This is a broken promise whose eventual reason for breakage will never be known, and the eventual reason it will never be known is "true" > .then( function(val) { console.log( val ); } , function(err) { > console.error( err ); }); > The second callback must be called with err bound to Q.reject(Q(true)), as that explains why the eventual reason for the first promise's failure will never be known. > > > Is it just a nonsense usage - most likely to be a programming error? > If so, what is the best / noisiest way to fail? > It is uncommon, but there's nothing incorrect or erroneous about it. -- Cheers, --MarkMReceived on Thursday, 6 June 2013 01:27:42 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC