Add a new language version for ES 6 features

[gbrail]

We should add a new flag:

Context.VERSION_ES_6

for features that are ECMAScript 6 only. That would include "arrow functions."

Support for arrow functions should be disabled unless the language level is set to this level.

[sainaen]

I feel that it could be confusing to have VERSION_ES_6 for arrow functions, while a lot of other ES6 features are already available at lower (or even all) levels: let (>=1.7), const (>=1.0), typed arrays (>=1.0), generators (well, it's ES6-ish, >=1_7), destructuring (>=1.0, but shorthand destructuring >=1_8), Array.prototype.find and Array.prototype.findIndex (>=1.0).

Also, I think we shouldn't name language versions supported by Rhino after ES standard version, as there's no direct link between those two at the moment. Rhino language version are more about features rather than full compliance with the spec of particular version.

So I propose to use VERSION_1_9 instead, that will enable at least arrow functions, maybe something else -- for example, we could move recently implemented typed arrays and Array.prototype methods to that version as well.

[eshepelyuk]

My 5 cents on this. Having gut feeling that arranging all the features properly according to specification version could become a nightmare for small number of developers working on this fork. Although we could extend usage of new flag VERSION_ES_6 to current RHINO features that are using old flags. So we could introduce evilutionary enhancement.

[gbrail]

I agree that putting a version on ALL the features would be too much -- for instance, are we going to go back to those "find" and "findIndex" functions and make them conditional? I think that's too much work.

However, I thought that perhaps arrow functions, in particular, should be subject to language version because they are a different syntax. I don't think there's a compatibility risk. However, the Node team chose to have a separate flag ("--harmony-proxies") to enable ES 6 features, so I thought that we should consider the same thing.

On Wed, Jan 14, 2015 at 10:04 PM, Evgeny Shepelyuk <notifications@github.com

wrote:

My 5 cents on this. Having gut feeling that arranging all the features properly according to specification version could become a nightmare for small number of developers working on this fork. Although we could extend usage of new flag VERSION_ES_6 to current RHINO features that are using old flags. So we could introduce evilutionary enhancement.

— Reply to this email directly or view it on GitHub https://github.com/apigee/rhino/issues/26#issuecomment-70043660.

greg brail | apigee https://apigee.com/ | twitter @gbrail http://twitter.com/gbrail

[eshepelyuk]

In fact I've proposed to use new version flag for conditions for find and findIndex in issue #24 raised by @sainaen

[gbrail]

I agree that this stuff hasn't all been totally pure in the past, but I want to consider two things:

First, the setting is called "languageVersion" and was used in previous versions of Rhino to enable and disable different versions of JavaScript.

Second, V8 introduced a bunch of features, such as typed arrays, before others, like arrow functions. Node.js 10.x supports typed arrays, whereas a special flag is required to get some of the other stuff. Since a bunch of us are running Node.js code in Rhino, this is relevant.

At the same time, 1.8 is a real version of the JavaScript language, whereas 1.9 and 2.0 are not, at least not yet. So how about this, at least for the new features that we're doing:

VERSION_1_9 adds typed arrays, the new array methods, and other things that have been in V8 for a while. (We will go back to the typed arrays and "findIndex" stuff and change it to support this version only.) This version is sort of a V8-like "1.8 plus some extra features" release.

VERSION_ES_6 adds arrow functions. Other things from ES6 would be added to this version as we implement them.

This is easy for me to do any time, but please let me know what you think!

[eshepelyuk]

Sounds reasonable, as for me - lets proceed with this approach. I could adjist find / findIndex as soon as we have new language flags.