On Wed, Feb 5, 2014 at 6:37 AM, Mark S. Miller <[email protected]> wrote:
> On Wed, Feb 5, 2014 at 12:43 AM, Brendan Eich <[email protected]> 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. > Should be *by* 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 > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
