It seems like slashdot has a story on this, and as usual, it's completely misleading and sensationalist, and anti-MS (without mentioning any other ES4 dissenters) to boot:
http://tech.slashdot.org/article.pl?sid=08/08/16/1552227 sigh... Brendan Eich wrote: > It's no secret that the JavaScript standards body, Ecma's Technical > Committee 39, has been split for over a year, with some members > favoring ES4, a major fourth edition to ECMA-262, and others > advocating ES3.1 based on the existing ECMA-262 Edition 3 (ES3) > specification. Now, I'm happy to report, the split is over. > > The Ecma TC39 meeting in Oslo at the end of July was very productive, > and if we keep working together, it will be seen as seminal when we > look back in a couple of years. Before this meeting, I worked with > John Neumann, TC39 chair, and ES3.1 and ES4 principals, especially > Lars Hansen (Adobe), Mark Miller (Google), and Allen Wirfs-Brock > (Microsoft), to unify the committee around shared values and a common > roadmap. This message is my attempt to announce the main result of > the meeting, which I've labeled "Harmony". > > Executive Summary > > The committee has resolved in favor of these tasks and conclusions: > > 1. Focus work on ES3.1 with full collaboration of all parties, and > target two interoperable implementations by early next year. > 2. Collaborate on the next step beyond ES3.1, which will include > syntactic extensions but which will be more modest than ES4 in both > semantic and syntactic innovation. > 3. Some ES4 proposals have been deemed unsound for the Web, and are > off the table for good: packages, namespaces and early binding. This > conclusion is key to Harmony. > 4. Other goals and ideas from ES4 are being rephrased to keep > consensus in the committee; these include a notion of classes based > on existing ES3 concepts combined with proposed ES3.1 extensions. > > Detailed Statement > > A split committee is good for no one and nothing, least of all any > language specs that might come out of it. Harmony was my proposal > based on this premise, but it also required (at least on the part of > key ES4 folks) intentionally dropping namespaces. > > This is good news for everyone, both those who favor smaller changes > to the language and those who advocate ongoing evolution that > requires new syntax if not new semantics. It does mean that some of > the ideas going back to the first ES4 proposals in 1999, implemented > variously in JScript.NET and ActionScript, won't make it into any ES > standard. But the benefit is collaboration on unified successor > specifications to follow ES3, starting with ES3.1 and continuing > after it with larger changes and improved specification techniques. > > One of the use-cases for namespaces in ES4 was early binding (use > namespace intrinsic), both for performance and for programmer > comprehension -- no chance of runtime name binding disagreeing with > any earlier binding. But early binding in any dynamic code loading > scenario like the web requires a prioritization or reservation > mechanism to avoid early versus late binding conflicts. > > Plus, as some JS implementors have noted with concern, multiple open > namespaces impose runtime cost unless an implementation works > significantly harder. > > For these reasons, namespaces and early binding (like packages before > them, this past April) must go. This is final, they are not even a > future possibility. To achieve harmony, we have to focus not only on > nearer term improvements -- on "what's in" or what could be in -- we > must also strive to agree on what's out. > > Once namespaces and early binding are out, classes can desugar to > lambda-coding + Object.freeze and friends from ES3.1. There's no need > for new runtime semantics to model what we talked about in Oslo as a > harmonized class proposal (I will publish wiki pages shortly to show > what was discussed). > > We talked about desugaring classes in some detail in Oslo. During > these exchanges, we discussed several separable issues, including > classes, inheritance, like patterns, and type annotations. I'll avoid > writing more here, except to note that there were clear axes of > disagreement and agreement, grounds for hope that the committee could > reach consensus on some of these ideas, and general preference for > starting with the simplest proposals and keeping consensus as we go. > > We may add runtime helpers if lambda-coding is too obscure for the > main audience of the spec, namely implementors who aim to achieve > interoperation, but who may not be lambda-coding gurus. But we will > try to avoid extending the runtime semantic model of the 3.1 spec, as > a discipline to guard against complexity. > > One possible semantic addition to fill a notorious gap in the > language, which I sketched with able help from Mark Miller: a way to > generate new Name objects that do not equate as property identifiers > to any string. I also showed some sugar, but that is secondary at > this point. Many were in favor of this new Name object idea. > > There remain challenges, in particular getting off of the untestable > and increasingly unwieldy ES1-3.x spec formalism. I heard some > generally agree, and no one demur, about the ES4 approach of using an > SML + self-hosted built-ins reference implementation (RI). > > We are going to look into stripping the RI of namespaces and early > binding (which it uses to ensure normative self-hosted behavior, not > susceptible to "user code" modifying the meaning of built-ins), > simplifying it to implement ES3.1plus or minus (self-hosted built-ins > may require a bit more magic). More on that effort soon. > > ES3.1 standardizes getters and setters that were first implemented at > Mozilla and copied by Apple and Opera. More such de-facto > standardization is on the table for a successor edition in the > harmonized committee. > > I heard good agreement on low-hanging "de-facto standard" fruit, > particularly let as the new var, to match block-scoped const as still > proposed (IIRC) in 3.1. Also some favorable comments about simple > desugarings such as expression closures and destructuring assignment, > and other changes in JS1.7 and 1.8 that do not require new runtime > semantic models. > > Obviously, these require new syntax, which is appropriate for a major > post-3.1 "ES-harmony" edition. Syntax is user interface, there's no > reason to avoid improving it. What's more, the intersection semantics > of extended ES3 implementations conflict and choke off backward- > compatible *semantics* for syntax that may even parse in all top four > browsers (e.g., functions in blocks). > > Both the appropriateness of new syntax, and the need to make > incompatible (with ES3 extensions) semantic changes, motivate opt-in > versioning of harmonized successor edition. I believe that past > concerns about opt-in versioning requiring server file suffix to MIME > type mapping maintenance were assuaged (browsers in practice, and > HTML5 + RFC 4329, do not consider server-sent Content-Type -- the web > page author can write version parameters directly in script tag type > attributes). > > Some expressed interest in an in-language pragma to select version; > this would require immediate version change during parsing. It's a > topic for future discussions. > > The main point, as important as cutting namespaces in my view, is > that the committee has a vision for extending the language > syntactically, not trying to fit new semantics entirely within some > combination of existing "three of four top browsers" syntax and > standard library extensions. > > As Waldemar Horwat (Google) said on the final day, the meeting was > seminal, and one of the most productive in a long while. Much work > remains on 3.1 and Harmony, but we are now on a good footing to make > progress as a single committee. > > /be > > _______________________________________________ > Es3.x-discuss mailing list > [EMAIL PROTECTED] > https://mail.mozilla.org/listinfo/es3.x-discuss > > _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
