- From: Sean Hogan <shogun70@westnet.com.au>
- Date: Mon, 03 Jun 2013 09:37:39 +1000
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: "www-dom@w3.org" <www-dom@w3.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Anne van Kesteren <annevk@annevk.nl>
On 20/05/13 12:05 PM, Tab Atkins Jr. wrote: > On Sun, May 19, 2013 at 6:04 PM, Sean Hogan <shogun70@westnet.com.au> wrote: > >>>> c. `then` doesn't need to be the feature-test for Promise objects, >>>> and doesn't need to be a forbidden method of non-Promise objects. >>> I don't understand how this is a result of your proposal. >> >> >> A contrived example: >> >> var Data = { >> x: 1, >> y: 2, >> then: function() { } >> } >> >> Future.accept() >> .then(function() { >> return Data; >> }) >> .done(function(value) { >> someExternalCodeExpectingData(value); >> }); >> >> This chain will stall (silently) because `Data` will be treated as a Promise >> object. >> Replace the .then() call with .thenfu and the following won't stall: >> >> .thenfu(function(value) { >> this.accept(Data); >> }) > Yes, this is why I don't understand. You can do the same thing in > Futures, once Anne fixes the spec like he's saying he will, by doing: > > .then(function(val) { > return Future.accept(Data); > } > > This unconditionally stores the Data object in the Future, without > regards to whether Data is a thenable, a native Future, or a plain > value. > > Since the spec hasn't been updated, is there more info on how `Future.accept()` will be fixed to support that code sample?
Received on Sunday, 2 June 2013 23:38:17 UTC