maian330 at gmail.com
Sat Aug 16 22:19:43 PDT 2008
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:
Brendan Eich wrote:
> 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
> 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.
> Es3.x-discuss mailing list
> Es3.x-discuss at mozilla.org
More information about the Es-discuss