Re: Deprecating Future's .then()

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:12 UTC