W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Deprecating Future's .then()

From: Sean Hogan <shogun70@westnet.com.au>
Date: Mon, 03 Jun 2013 09:37:39 +1000
Message-ID: <51ABD743.30506@westnet.com.au>
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:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC