On Sep 8, 2010, at 12:52 PM, David Herman wrote: >>>> But since Traits seems to be blocked from advancing, >>> >>> Is there someplace I should read to understand why Traits cannot advance? >> >> I asked MarkM off-list what the reason was, and he replied that there >> was an objection (raised by Waldemar?) to how class evolution was >> handled. > > My feeling, and I think the feeling of others at the meeting when we > discussed traits, was that traits.js is a very nice library but that it > doesn't offer enough to the language to warrant standardization, at least > yet. The fact that there would be performance benefits to built-in > implementations of traits isn't enough to make the case. IMO, libraries > should generally be very widely used and very stable before they are added to > the ES standard library.
The specific objection articulated by Waldemar was the "version evolution problem", where a downstream client and upstream library evolve independent, conflicting traits. If I remember Waldemar's point correctly, he wants version 1 library users to be shielded from any conflict between their client code, however it evolves, and version 2 of the library, however it evolves. AFAIK this is nowhere near a solved problem in PLT. The general objection, or more accurately, recommendation (since everyone I know thinks highly of Mark and Tom's http://traitsjs.org work), was what Dave said: the code was too good as library code to win "hardcoding" in dedicated syntax in a near-term edition of ECMA-262. I pointed out on this list that JS VMs have a hard time optimizing traits' shared methods -- really, optimizing away multiple function objects resulting from evaluation of a single nested function expression or definition: https://mail.mozilla.org/pipermail/es-discuss/2010-February/010830.html https://mail.mozilla.org/pipermail/es-discuss/2010-February/010832.html But this problem can be solved by an extension such as http://wiki.ecmascript.org/doku.php?id=strawman:const_functions Specifically the bit I proposed at the July TC39 meeting at Microsoft, which Mark nicely wrote up in detail at http://wiki.ecmascript.org/doku.php?id=strawman:const_functions#joining So if traits.js does not need syntax to be optimized, it still might merit syntax for usability. But we would need more experience with it, and a larger user base for it, before standardizing. We in TC39 generally hesitate to standardize library code. We certainly extended the JS standard library in ES5, but notably with JSON, which is a fixed spec that will never change (only be replaced some day, Doug says -- that day is far off, I say). The ES5 meta-programming API was a synthesis and extended rationalization of precursors such as getters and setters including their "__" APIs (__lookupGetter__, etc.) first added by Mozilla over ten years ago, and cloned into other browsers. Function.prototype.bind was a common feature of JS libraries, although not always the same and we're only now finding conflicts (with MooTools, which is adapting to avoid the conflict, IIRC). This was more than enough library extension for ES5, and with implementations only rolling out now in betas or preview releases, the verdict on how well we did is not yet in. I am sympathetic to objections of the form "Ecma TC39 should not under-evolve the language and its standard library and thereby require all developers to develop and download big non-standard libraries", but it is not the only consideration. On the other side, library standardization should never be rushed. Just look at what happened with C! We really do not have the competence in TC39 (no one group does, yet, IMHO) to standardize JS library code aggressively. There are indeed notorious language and library gaps to fill, but we are focusing on the language gaps, with the Scheme philosophy of adding missing primitives that compose well and have good general usability and "safety", while treading carefully with the library gaps. Traits could be part of the standard library at some point if they become popular to the same degree as JSON or bind, and provided we can overcome Waldemar's objection. Waldemar has been concerned with the "version evolution problem" since the original JS2/ES5 days. But we failed to solve it with ES4, so I'm not going to hold out for utopia (no-place). JS is a worse-is-better language, too much so, but getting over it. JS is never to be a superb better-is-better (which usually means never-is-better, which means users hacking library and app code have to reinvent wheels constantly) language. Parting shot: I find the zero-inheritance classes-as-sugar proposal to be lukewarm beer, and want to spit it out. I'm with Tucker. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
