On Oct 23, 9:54 am, Attila Szegedi <[email protected]> wrote: > On 2009.10.23., at 15:07, Norris Boyd wrote: > > > > > > > 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 bughttps://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. > > This seems to imply that we don't need a new > FEATURE_WRITE_READONLY_PROPERTIES, but rather should scope this > behaviour to FEATURE_STRICT_MODE, would you agree?
Yes, agreed. And not just FEATURE_STRICT_MODE but also ES5 strict mode (both of which should be equivalent, but that's another topic). > > > 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. > > There are some name collisions, i.e. some current JS libraries (case > in point: prototype.js) define Function.bind, and I have a vague > understanding that they'll fail if it's already present. > Seehttp://www.prototypejs.org/api/function/bind I think this was discussed by the ES5 committee--certainly breaking Prototype would be a concern for browser vendors. A quick experiment on current Rhino shows that the new builtin Function.bind can be overridden, so I imagine the expectation is that Prototype will override the existing, or that it will be compatible. > > > 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. > > Sorry, I was a bit confused - I was thinking JavaScript 1.9. > Information on Mozilla website regarding versions is scarce (or I'm > not clever enough to dig it up), but Wikipedia entry on JavaScript > refers to "1.9" as being "1.8 + ECMAScript 5". But Brendan's thoughts > actually clarify this; if I understand it correctly, we can have ES5 > integrated into any versions, and it shouldn't cause trouble, right? That's the intent as I understand it. > > (Hm, I guess I *should* finally read through the ES5 spec so I don't > have to fake that I know what am I talking about...) > > Attila. > > > > > Thanks, > > Norris > > _______________________________________________ > > dev-tech-js-engine-rhino mailing list > > [email protected] > >https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
