W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2013

Re: Deprecating Future's .then()

From: Mark S. Miller <erights@google.com>
Date: Wed, 5 Jun 2013 18:27:10 -0700
Message-ID: <CABHxS9gA3PUqR6+wm9ofNMAPxOKMZucMbTemYrNmFiuFw3jVOA@mail.gmail.com>
To: Sean Hogan <shogun70@westnet.com.au>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Anne van Kesteren <annevk@annevk.nl>, Sam Tobin-Hochstadt <samth@ccs.neu.edu>, "www-dom@w3.org" <www-dom@w3.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Alex Russell <slightlyoff@google.com>
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
Received on Thursday, 6 June 2013 01:27:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:21 UTC