Identity of the project
Attila Szegedi
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.
Norris Boyd
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
Joran Greef
Simple: I would prefer to put in the effort to keep my code-base up to
date with Rhino, if that means we can break free from backwards-
compatibility phobia, which often tends to slow progress. It will take
guts but Rhino will be better in the end if it supports "a single JS
version" only.
Fast: I use Rhino as a JSON API server in production. It's certainly a
couple times slower than V8 or TraceMonkey. At this stage I would
switch to V8, except for the excellent access to Java that Rhino
offers. It would be great if the Rhino could be made to run faster.
Attila Szegedi
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?
> 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. See http://www.prototypejs.org/api/function/bind
> 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?
(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
> dev-tech-js-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
Norris Boyd
> > "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
> > dev-tech-js-engine-rh...@lists.mozilla.org
> >https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
Norris Boyd
> I would like Rhino to be: simple and fast.
>
> Simple: I would prefer to put in the effort to keep my code-base up to
> date with Rhino, if that means we can break free from backwards-
> compatibility phobia, which often tends to slow progress. It will take
> guts but Rhino will be better in the end if it supports "a single JS
> version" only.
I think there's some value in maintaining backwards compatibility,
particularly in regard to the JS language version, since the scripts
being evaulated/parsed are often out of the control of the Rhino
embedders themselves. That being said, SpiderMonkey has been dropping
support for old JavaScript language versions (most notably the pre-
ECMA JavaScript 1.2), and Rhino should do the same.
>
> Fast: I use Rhino as a JSON API server in production. It's certainly a
> couple times slower than V8 or TraceMonkey. At this stage I would
> switch to V8, except for the excellent access to Java that Rhino
> offers. It would be great if the Rhino could be made to run faster.
No argument on speed. It'd be great to improve parsing and execution
speed, and I expect there's some low-hanging fruit. Patches welcome!
Marc Guillemot
> ...
>> 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.
HtmlUnit already uses recent features from Rhino HEAD. I haven't noticed
problems with the prototype tests of our tests suite but with the
MooTools tests. MooTools doesn't try to override Function.bind, but it
defines it by itself only if it is not already available (this is what
they do for all the functions that they define) and the problem is that
Rhino's bind function (or ES5's one) doesn't behave like MooTools' one,
what breaks some functionality. To still be able to support MooTools,
HtmlUnit now just deletes Function.bind.
Cheers,
Marc.
--
Web: http://www.efficient-webtesting.com
Blog: http://mguillem.wordpress.com