On Oct 23, 8:19 am, Attila Szegedi <[email protected]> wrote: > Folks, > > I was looking at few things today in Bugzilla, one of them is > <https://bugzilla.mozilla.org/show_bug.cgi?id=519933 > >. The gist of it is that Rhino CVS HEAD code now conforms to TC39 > ES3.1 Draft of 9-Feb-2009, 8.12.4, step 2 and will throw a TypeError > when assigning to a property that has a getter but has no setter. > However, this was not really prohibited by earlier versions of either > ECMAScript or JavaScript. Rhino itself doesn't only support ECMAScript > 5, it actually supports a whole range of JavaScript versions (and, > FWIW, ECMAScript 5 will only be used in JavaScript 2.0). > > This brings about a question about the identity of the project. What > does Rhino strive to be? Do we want to be an ECMAScript runtime, or a > JavaScript runtime? What versions of ECMAScript and JavaScript do we > want to support with each release? > > I believe that Rhino should be a JavaScript runtime, that is, not a > purely ECMAScript runtime, but also incorporating JavaScript features > as documented at <https://developer.mozilla.org/en/JavaScript> > > As for version support... Rhino now has an awful lot of backwards > compatibility switches in it, and I'm a bit worried about maintaining > all of them. > > Now, what version of JavaScript do we want to support? Right now, > Rhino has a bunch of VERSION_x_y constants that allow it to run in > older JS runtime compatibility mode. How far in the past do we want to > support that? Do we want Rhino to support a range of older JavaScript > versions, or do we declare that we will support whatever is the latest > JavaScript version, and tell people who need older JavaScript > functionality that they should go and use an older Rhino version? > > I think we should be consistent about this. Current CVS HEAD seems to > have ECMAScript 5 functionality enabled by default (including the > above mentioned TypeError on setting a property with a getter but no > setter) that will ruin compatibility with previous JavaScript > versions. We either want every such functionality to be conditional > on, say, VERSION_2_0 (since JS 2.0 will be the ECMAScript 5 compliant > JS), or we should just throw away the compatibility idea and say that > going forward, we're only supporting a single JS version. > > Attila.
See bug https://bugzilla.mozilla.org/show_bug.cgi?id=523846 "Assignments to a property that has a getter but not a setter should only throw a TypeError in strict mode". This bug is filed against SpiderMonkey, but applies to Rhino as well as you point out. So for this particular issue, we will change default behavior to be compatible with previous JavaScript and ECMAScript versions. I asked Brendan back in the summer what the plan was for version numbers and support of ES5 with Spidermonkey/Firefox. He said "...we are hoping to get away with adding everything under the default version, so you won't have to opt in. ES5, formerly ES3.1, had "no new syntax" as its mantra from the start, and the only opt-in versioning we have is for either new syntax or bug-for-bug compatibility." I've been trying to follow that, with the plan that we don't have to choose between ES5 support and "JavaScript" support. There are some cases where the ES5 work has resulted in a minor semantics change, but as far as I know they've all been cases where the JavaScript implementations in browsers disagreed and ES5 serves to standardize this divergent behavior. If you know of other cases where backwards compatibility is broken, please bring them up so they can be addressed. I'm not sure what you mean by JavaScript 2.0--AFAIK that's the name for the proposal that Waldemar Horwat put together that morphed into ES4 that was then put on the back burner in favor of ES3.1 which was renamed ES5. My hope is that the next JavaScript version of Rhino will be 1.8 if we can implement generator expressions, but I'm not planning on tying ES5 support to a particular JS version number. Thanks, Norris _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
