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,
--MarkM