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 10:51:17 +1000
Message-ID: <51AFDD05.8020909@westnet.com.au>
To: Anne van Kesteren <annevk@annevk.nl>
CC: Sam Tobin-Hochstadt <samth@ccs.neu.edu>, "Tab Atkins Jr." <jackalmage@gmail.com>, "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 4/06/13 11:48 PM, Anne van Kesteren wrote:
> On Tue, Jun 4, 2013 at 8:55 AM, Sam Tobin-Hochstadt <samth@ccs.neu.edu> wrote:
>> Thinking about this more, I'm now unsure why both `fulfill` and
>> `resolve` are needed given the semantics of `.chain()` and `.then()`
>> described below.
>>
>> In particular, if `.then()` chains recursively *before* calling the
>> callback, then there's no difference between:
>>
>>      Future.resolve(x).then(v => ...)
>>
>> and
>>
>>      Future.fulfill(x).then(v => ...)
>>
>> even when `x` is a promise.  The only way to observe this is with `.chain()`.
>>
>> Thoughts?
> I'm just going to try to repeat what you said here to make sure I understand.
>
> Promise.resolve(val) creates a promise of val, regardless of whether
> val is a promise, has a callable then property, or anything like that.
> (In that sense it is equivalent to Future.accept() today.)
>
> promise.then() keeps unwrapping promise's internal value until it no
> longer has a callable then property at which point it invokes the
> relevant callback passed to promise.then(). (Exact algorithm TBD after
> broader agreement.)
>
> promise.chain() invokes its relevant callback with promise's internal value.
>
> promise.then() and promise.chain() return value (newPromise) is
> resolved with the return value of their callbacks after it has been
> unwrapped once.

I just realized that the current DOM spec for Futures / Promises already 
facilitates something like .chain(). This would be done by negating 
usage - that is, Future.reject() is used to accept and rejectCallbacks 
are used for accepted values. For example:

     var innerValue = { x: 1, y: 2 };
     var count = 0;
     function accept( val ) { var f = Future.reject( val ); f.index = 
count++; return f; }
     var startFuture = accept( accept ( accept( innerValue ) ) );
     Future.reject( startFuture )
     .then( onreject, onaccept )
     .then( onreject, onaccept )
     .then( onreject, onaccept )
     .then( onreject, onaccept ) // onaccept should get innerValue and 
thus "fail"
     .done(
         function(val) {
             if (val === innerValue) console.log("Found innerValue");
             else throw "Couldn't find innerValue";
         },
         onreject );

     function onaccept(val) {
         console.log("Chaining is working. Index: ", val.index);
         return val;
     }

     function onreject(val) {
         console.log("Some mistake. You shouldn't be here.");
     }


Probably most would consider this an example of "garbage in / garbage out".

But ...

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?
Received on Thursday, 6 June 2013 00:51:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC