The versioning issues in ECMAScript are tough. We ran into these same
problems when we were working with TC39 to formulate a versioning plan
for what became ES5. None of the alternatives are really that great,
but you likely need to pick one to make progress.
I would caution you about adding more modes to ECMAScript. That trick
works once or twice, but if you keep adding modes over the years, you
eventually end up with something extremely complicated. IE is
starting to suffer from this pain as their number of rendering modes
compounds with each release.
Adam
On Thu, Dec 15, 2011 at 3:38 AM, Andy Wingo wrote:
> Hello all,
>
> As you probably know, the ECMA TC39 committee is slowly approaching
> consensus on a new revision of the ECMAScript language. The interim
> results of this process have gone under various names: Harmony, ES.next,
> and ES6. They are the same thing. This mail is intended to open the
> discussion on what to do now regarding ES6 in JSC.
>
> Here is the latest draft ES6 spec, from 7 November:
>
> http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_drafts&cache=cache&media=harmony:working_draft_ecma-262_edition_6_11-7-11.pdf
>
> Discussion takes place among committee members. Some discussion also
> takes place in public, on es-disc...@mozilla.org.
>
> We cannot consider implementing ES6 now, as the final document is not
> out, and some things are likely to change. It only makes sense to look
> at the features for which broad consensus exists.
>
> So, what is agreed upon in the ES6 spec? I would answer this by
> mentioning the parts of ES6 that folks are working on both for
> SpiderMonkey and for V8. These are:
>
> 1. Block-scoped `let' and `const'
> (https://bugs.webkit.org/show_bug.cgi?id=31813)
> 2. typeof 'null' -> 'null', not 'object'
> 3. Proxies
> 4. Collections (maps, sets, weak maps)
>
> Things that are not implemented by multiple JS engines, but otherwise
> are close to agreement:
>
> 5. Modules
> 6. Destructuring binding
> 7. Parameter default values, rest parameters
> 8. Quasi-literals
> 9. Generators, iterators, comprehensions
> 10. Binary data
>
> Things that will probably change:
>
> 11. Classes, <|, .{
>
> See http://wiki.ecmascript.org/doku.php?id=harmony:proposals for more
> information.
>
> V8 currently compiles in support for 1-4, but disabled behind a runtime
> flag. I think that with the nightly Chromium builds you can run it with
> --harmony to enable these features. Modules are being worked on for V8,
> but not finished AFAIK.
>
> * * *
>
> One big problem for ES6 is "how to get there from here": how to enable
> the new language features without breaking the web. The current answer
> is to define a new mode, and allow code to opt-in to that mode.
>
> Recall that ES5 defines "strict mode", a new mode of execution for JS.
> Let's call the other mode "classic mode". ES6 defines a third "extended
> mode", which builds on strict mode, and enables the new features.
>
> ES6 does not yet define how extended mode is entered, however. Some ES6
> functionality is incompatible both with classic mode and with strict
> mode, so it has to be an opt-in thing, perhaps via
