On Wed, Feb 5, 2014 at 12:43 AM, Brendan Eich <brendan at mozilla.com> wrote:

> 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?


I see no need to reopen this yet again. At this last meeting, we declared a
new consensus, to keep the .cast and .then level, dispense with the .accept
(previously renamed .resolve) and .chain level, and to rename .cast to
.resolve.

This kills the September AP2 consensus, in that we are no longer
constraining the .then level's mechanics to be compatible with introducing
(whether now or in the future) a .chain level. The September consensus was
a compromise, in the "do both" mode that standards committees are tempted
by. I have a deeper appreciation of those temptations now, having promoted
it at the time. Given that we were trying to do both, Todd's AP2 was a
wonderful way to minimize the pain. But I am now proud to see our committee
once again rise above the "do both" failure mode.

IMO, the most important argument against "do both" is that it would lead to
perpetual confusion, as some libraries are written to the .then style and
others are written to the .chain style. With AP2, these would live together
as well as possible, but that's still not well.

Regarding the comments in this thread, I haven't engaged since I have not
seen any new points raised. All the old arguments are publicly archived. If
you're about to repost a previously posted argument, please instead just go
read the previously posted response. No one convinced anyone of very much
that time, and repetition is unlikely to do better.

The one remaining open issue for me is the means of flattening the output
side of a .then operation. The end-of-september "consensus" flattened one
level, but nominal typing and use of internal properties. The current spec
flattens using .then. The change was made to make subclassing more flexible
in ways I have yet to appreciate. But since we are no longer trying to
co-exist with .chain, now or in the future, I no longer object to using
.then for the output flattening of .then. I am fine with the .then spec as
currently written, in the context of the rest of our decisions at the end
of January meeting.


>
> /be
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140205/6748903b/attachment.html>

On Wed, Feb 5, 2014 at 12:43 AM, Brendan Eich <brendan at mozilla.com> wrote:

> 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?


I see no need to reopen this yet again. At this last meeting, we declared a
new consensus, to keep the .cast and .then level, dispense with the .accept
(previously renamed .resolve) and .chain level, and to rename .cast to
.resolve.

This kills the September AP2 consensus, in that we are no longer
constraining the .then level's mechanics to be compatible with introducing
(whether now or in the future) a .chain level. The September consensus was
a compromise, in the "do both" mode that standards committees are tempted
by. I have a deeper appreciation of those temptations now, having promoted
it at the time. Given that we were trying to do both, Todd's AP2 was a
wonderful way to minimize the pain. But I am now proud to see our committee
once again rise above the "do both" failure mode.

IMO, the most important argument against "do both" is that it would lead to
perpetual confusion, as some libraries are written to the .then style and
others are written to the .chain style. With AP2, these would live together
as well as possible, but that's still not well.

Regarding the comments in this thread, I haven't engaged since I have not
seen any new points raised. All the old arguments are publicly archived. If
you're about to repost a previously posted argument, please instead just go
read the previously posted response. No one convinced anyone of very much
that time, and repetition is unlikely to do better.

The one remaining open issue for me is the means of flattening the output
side of a .then operation. The end-of-september "consensus" flattened one
level, but nominal typing and use of internal properties. The current spec
flattens using .then. The change was made to make subclassing more flexible
in ways I have yet to appreciate. But since we are no longer trying to
co-exist with .chain, now or in the future, I no longer object to using
.then for the output flattening of .then. I am fine with the .then spec as
currently written, in the context of the rest of our decisions at the end
of January meeting.