Re: Deprecating Future's .then()

On 3/06/13 9:37 AM, Sean Hogan wrote:
> 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?
>
>
>

Since the spec isn't going to support this scenario, shouldn't there be 
a note about it? Something like:

If a .then() or .catch() callback returns an object that has a .then() 
method that is incompatible with DOM Promises (possibly because it is 
not a Promise-like object) then the behavior of .then()/.catch() is 
undefined.