Tuesday, January 19th, 2010

ECMAScript Edition 5: WebKit JavaScriptCore Progress

Category: JavaScript

We have a new bible. ECMAScript Edition 5 was voted (despite annoying folk like IBM who seem to only get in the way) in. So, when do we get to play?

Over on the Qt blog, Kent has posted on the progress that has been made, and what there is to go, for this to be seen in JavaScriptCore (normally the V8 team releases once the language is out there):

Features implemented in JavaScriptCore

This is stuff that’s already in WebKit trunk. I’ve included links to relevant Bugzilla tasks in case you’d like more information (e.g. have a look at the patches).

  • Array extras”: Array.prototype.{indexOf,lastIndexOf,every,some,forEach,map,filter,reduce,reduceRight}:
    These have been in JSC for years. I’m not sure how conformant the implementations are, though.

Features not implemented in JavaScriptCore

  • Strict mode: I’m not aware of any work that’s been done to support strict mode yet. It involves making the parser/compiler recognize the “use strict” directive and adapting execution according to the rules given in annex C of the ES5 specification. (The annex lists 20 restrictions/exceptions that apply to strict mode.)

Hopefully work is moving fast for Mozilla, Opera, Google and Microsoft too!

Posted by Dion Almaer at 6:51 am
54 Comments

++++-
4.3 rating from 38 votes

54 Comments »

Comments feed TrackBack URI

that it is unwise to treat favored libraries as retroactively part of the standard
Make a better premise, because this one is faulty. For one, it did not become part of the standard “retroactively”. JSON2 was adapted by ECMA Standards since it was THE standard. JSON.js and JSON2.js also weren’t “favored” libraries, they where THE libraries that provided THE implementation of the functionality everything else are “convenience” libraries.
.
Also consider ‘getElementsBySelector’ and the entire debate on how to name it. I think we saw ~5 versions pass by at one time? An utter waste of time in a language where it’s crackerjack easy to create aliases and convenience wrappers.
.
I am also sure that in hindsight, Doug would’ve renamed it as he did with Object.beget, but then JSON2.js was already THE standard.
.
Stringify is ok, not perfect, but I can work with it.

Comment by BenGerrissen — January 25, 2010

timdown,

For what it’s worth now, yes, I think that phrase just stuck out at me and I didn’t read the context correctly.

Thanks! I was wrong about that example though heh.

* * *

BenGerrissen,

Make a better premise, because this one is faulty. For one, it did not become part of the standard “retroactively”.

Yes, they did. That is the fundamental part of the logic of calling it “backwards compatibility” to respect the library’s conventions in the standard. It has to have some point to look “backwards” to in order to be compatible with it.

JSON2 was adapted by ECMA Standards since it was THE standard. JSON.js and JSON2.js also weren’t “favored” libraries, they where THE libraries that provided THE implementation of the functionality everything else are “convenience” libraries.

How did json2.js become the standard? When was it standardized? We’re discussing the ECMA-262 standard, in case you’re not aware. And since json.js and json2.js conflict, how is one favored over the other?

Also consider ‘getElementsBySelector’ and the entire debate on how to name it.

Note first that this is a DOM API, not ECMA-262. Note second that the decision was made to make its naming consistent with the rest of the relevant DOM API, rather than use the naming convention of some favored library as if it had retroactively become part of the standard.

I am also sure that in hindsight, Doug would’ve renamed it as he did with Object.beget, but then JSON2.js was already THE standard.

It didn’t become part of the standard until September 2009. You’re incorrect. You’re abusing the term “standard” to reflect a concept it doesn’t mean in this context. The standard refers to ECMA-262. What you’re discussing is a de facto standard. I accept that de facto standards are a real part of shaping a formal standard, but I don’t accept that by adopting them we are to treat them as targets for “backwards compatibility”. Doing so unnecessarily assigns them a value they don’t have.

Stringify is ok, not perfect, but I can work with it.

Agreed.

* * *

I want to revise a point to Breton that I made earlier too:

json2.js is already widely deployed, and from the start was setup in a certain way to fall back to some future native version.

(Emphasis mine.) This is a basic “best practices” issue. Whenever introducing a new global object or method in Javascript, it’s wise to default to the native version if it exists. json2.js is not special in this respect, and certainly not a predictor of future standards evolution, and certainly not warranted special privileges of influence on this basis.

Comment by eyelidlessness — January 25, 2010

Basically, we agree on the main topic and am just going to ignore your nitpicking on whats what wether you’re right or wrong… You’re entitled to your opinions, you’re just not making yourself popular by going at it in this way, but hey, to each his own.
.
Enjoy.

Comment by BenGerrissen — January 25, 2010

I’m not really interested in being popular, but I am interested how you think I should “go at it”. I’m not sure what else I can do but express my point and clarify where it’s misunderstood. I’ve tried to steer clear of making it about personality, instead focusing on the substantive facts and context. What am I missing? This is a genuine question.

Comment by eyelidlessness — January 25, 2010

Leave a comment

You must be logged in to post a comment.