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 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.
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
[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
