I can understand the "you can't have your cake and eat it too" sentiment. Indeed, I do think that having `.then()` and `.chain()` in the spec is a mistake. The only thing that saddens me (and this also with some other parts of the spec, such as Object.create) is that `.then()` is not an orthogonal and composable primitive, it's a multi-method on top of simpler primitives, but as with other parts of JavaScript, the simpler, orthogonal primitives are not available for users to derive more complex functionality from easily. That is, these higher-level primitives provide support to a class of higher-level use cases, but not the necessary basis to support these use cases in general, and this is a bummer for modularity and re-usability. More so, I do think that just following de-facto standards without acknowledging that there might be "bugs" on them you want to fix when they are cheap to do so (i.e.: now, rather than after it becomes standard) really bothers me. Fixing libraries today, specially with a relatively new thing such as Promises/A+ is relatively "cheap."
At any rate, I'm just venting now, and I agree that the spec should only support either one or the other (even if `.then()` is just a combinator, the addition of it on the specs would lead to unnecessary headache, since it doesn't compose cleanly with other constructs). I am just sad that the specs are once again favouring the higher-level, limited use cases. On 5 February 2014 12:39, Mark S. Miller <[email protected]> wrote: > > > > 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 > > -- -- Quildreen "(Soreλ\a)" Motta (http://robotlolita.github.io/<http://killdream.github.com/> ) *— JavaScript Alchemist / Minimalist Designer / PLT hobbyist —*
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
