- From: Sean Hogan <shogun70@westnet.com.au>
- Date: Thu, 06 Jun 2013 10:51:17 +1000
- 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:56 UTC