Re: Deprecating Future's .then()
Sean Hogan <[email protected]>
| Newsgroups | gmane.comp.web.dom.general |
|---|---|
| Message-ID | <[email protected]> |
On 20/05/13 12:05 PM, Tab Atkins Jr. wrote: > On Sun, May 19, 2013 at 6:04 PM, Sean Hogan <[email protected]> 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?