Re: Deprecating Future's .then()

On Wed, Jun 5, 2013 at 6:12 PM, Sean Hogan <[email protected]> wrote:

> On 6/06/13 10:56 AM, Tab Atkins Jr. wrote:
>
>> On Thu, Jun 6, 2013 at 9:51 AM, Sean Hogan <[email protected]>
>> 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