Brendan Eich (2014-02-05T08:43:18.000Z)
Kevin Smith wrote:
>
>
>     - Promise.cast is renamed to Promise.resolve (remove old
>     Promise.resolve)
>     - Keep then, reject chain (NOT DEFER, reject!)
>     - Renaming .cast thus removes over-wrapping (always-wrap)
>     deoptimization in old Promise.resolve
>
> So basically, since September, we've seen:
>
> - A design proposal which achieved "consensus"
> - A spec implementation which completely ignored that "consensus"
> - And now a third design, which also throws out "consensus" and has 
> been implemented by precisely no-one
>
> And all of this over 200 to 300 LOC.
>
> These shenanigans are deeply disturbing.

I agree. I kept my nose out of it until it was front-and-center on the 
last day of the last TC39 meeting, and in context of threads here that 
were pushing (I was on side with you) to add .chain.

The design proposal in September did not have consensus, for real. That 
proposal was changed after the September meeting (Mark has details). The 
implementation in V8 then added .chain based on an understanding from 
the May 2013 meeting (multiple, "Rashomon" views of consensus).

There's still some concern about supporting Promise subclassing, too, 
but I think it can be handled without controversy (I could be wrong). It 
entails using the public-named methods (in case of overrides) 
consistently, and not using internal methods or other such shortcuts 
some of the time. Basically "always use .then".

Can we regain consensus on the September status quo ante, minus any "do 
both" half-hearted compromises that don't work? Mark, what do you think?

/be
domenic at domenicdenicola.com (2014-02-05T20:26:15.918Z)
Kevin Smith wrote:

> So basically, since September, we've seen:
>
> - A design proposal which achieved "consensus"
> - A spec implementation which completely ignored that "consensus"
> - And now a third design, which also throws out "consensus" and has 
> been implemented by precisely no-one
>
> And all of this over 200 to 300 LOC.
>
> These shenanigans are deeply disturbing.

I agree. I kept my nose out of it until it was front-and-center on the 
last day of the last TC39 meeting, and in context of threads here that 
were pushing (I was on side with you) to add .chain.

The design proposal in September did not have consensus, for real. That 
proposal was changed after the September meeting (Mark has details). The 
implementation in V8 then added .chain based on an understanding from 
the May 2013 meeting (multiple, "Rashomon" views of consensus).

There's still some concern about supporting Promise subclassing, too, 
but I think it can be handled without controversy (I could be wrong). It 
entails using the public-named methods (in case of overrides) 
consistently, and not using internal methods or other such shortcuts 
some of the time. Basically "always use .then".

Can we regain consensus on the September status quo ante, minus any "do 
both" half-hearted compromises that don't work? Mark, what do you think?