Tuesday, January 19th, 2010

ECMAScript Edition 5: WebKit JavaScriptCore Progress

Category: JavaScript

<p>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!

Related Content:

Posted by Dion Almaer at 6:51 am
54 Comments

++++-
4.3 rating from 38 votes

54 Comments »

Comments feed TrackBack URI

I still think JSON.stringify and JSON.parse are awfully named… why not just JSON.encode and JSON.decode?

Comment by rasmusfl0e — January 19, 2010

What rasmusfl0e said. I have hard times remembering which does what. Maybe I’m too used with PHP’s json_encode/json_decode, but still… stringify?

Comment by igstan — January 19, 2010

Theses names are for backward compatibility.
But I agree, they are awfull, I don’t know what Douglas Crockford was thinking when he named his methods.
.
JSON.parse()/serialize() would have been such a better choice. ECMAscript 5 should have standardized ‘serialize’ and suggested a ‘stringify’ alias. The backward compatibility/performance argument isn’t so revelant, considering that most of the time you serialize on the server and parse on the client.

Comment by ywg — January 19, 2010

“I don’t know what Douglas Crockford was thinking when he named his methods”

So the guy who complains about JS having “bad parts” is a total retarded designing languages as we can see.

Stringify??? what a stupid joke, now our beloved language gets more “bad parts” so he can write more books, now I see the point.

I vote for encode/decode and parse/serialize

Comment by Ajaxerex — January 19, 2010

Hey everybody, quit on the Crock hatin’!

Comment by Skilldrick — January 19, 2010

I’d go for ‘serialize’ over ‘stringify’ but I always seem to get mixed up with encode/decode as to which one I should be doing. But regardless, it’s too late now.

Comment by tercero12 — January 19, 2010

JSON.toString() would have continued the conventions already in JS… Ah, well.

Comment by rasmusfl0e — January 19, 2010

@rasmusfl0e: Using JSON.toString() one would expect it to give a string representation of the JSON object, as it does with other Javascript objects. In my eyes this is an even worse idea than JSON.stringify(), because it breaks peoples expectations.

BTW: JSON.stringify has been around for a long time in Crockfords json2.js, so people are used to using it. Seems kind of strange to me that people start bashing Crockford only now ECMA has made his idea a standard…

Comment by daanlib — January 19, 2010

Only Ajaxerex bashed Crockford, the rest simply makes a valid point.
.
To me, “stringify” is simply too cute… yuk

Comment by BenGerrissen — January 19, 2010

PS. nitpicking aside, YAY!

Comment by BenGerrissen — January 19, 2010

despite annoying folk like IBM who seem to only get in the way

Yeah. How dare they suggest that one tenth plus two tenths does not equal 0.30000000000000004! I think that ECMA’s decision to keep the existing float standard was the right choice, given the circumstances, but the circumstances were broken to begin with. IBM’s preferred float standard was not the best choice, but no other alternatives were offered. And the argument offered for keeping the highly imprecise standard (that changing it would break existing applications) is just obtuse. There’s no reason that a better float standard couldn’t be enabled with strict mode, which we’re all meant to start using anyway. It’s absolutely ridiculous that IBM has to take the heat alone for a bad decision (among bad choices) made by everyone involved. Their preferred float standard was not the best choice, but their rejection of the existing float standard is correct.

JSON.stringify is a ridiculous method name. Douglas Crockford has contributed a lot to the Javascript “world”, but he’s not infallible. And since when is library convention considered “backwards compatibility”? I’m not even sure I agree there should be a native JSON object. Why not Object.prototype.toJSON and String.prototype.toObject (I can see how this might be problematic, but I’m sure more thought put into it would find a better solution than a dedicated JSON object)? JSON.serialize certainly would have been better though, and it’s quite a lot more obvious what its purpose is. “Stringify” is actually quite vague: given the restrictions on what types are permitted in JSON, it’s not completely ridiculous to think “stringify” might mean “convert object’s invalid property values to strings as they would be represented in JSON”. Or something else equally ridiculous. “Serialize” is unambiguous and a conventional term for the behavior.

I’m also not too fond of the naming of Function.prototype.bind. It is, of course, based on PrototypeJS convention, but it conflicts with jQuery convention. If library convention counts for “backwards compatibility”, Function.prototype.bind should be verboten. Why not Function.prototype.scope or the no-more-verbose-than-the-rest-of-Javascript Function.prototype.assignScope?

Comment by eyelidlessness — January 19, 2010

Mozilla’s ES5 progress:
https://bugzilla.mozilla.org/show_bug.cgi?id=es5

Comment by TNO — January 19, 2010

Its likely JSON functions are named `stringify` and `parse` because its quite easy to swap the semantics of `encode/decode` and `serialize/deserialize`. With `parse` and `stringify` I don’t need to stop and think what the input and output to the function should be.

Comment by ratbeard — January 19, 2010

I guess it’s pretty clear that (rightly) the only thing people need is native JSON support. The rest of it seems to be based on this proposition > the rapid and massive growth/usage of javascript, coupled with the demonstrably excellent browser-based applications it powers, considered alongside the growing body of extremely confident libraries and articles promoting only the vast possibilities of this language, shows only that the language is broken. Speaking of Crockford.

Comment by nataxia — January 19, 2010

For goodness’ sake, what is wrong with JSON.parse and JSON.stringify as an API? It’s two names, and they’re quite clear and easy to remember. @eyelidlessness: “Function.prototype.bind should be verboten” because it’s different to jQuery convention? jQuery is a JavaScript library designed to make DOM interactions easier. Its API is not perfect and I see no reason why its conventions should be applied to the language specification.

Comment by timdown — January 20, 2010

Just fix it yourself in your libraries…

JSON.serialize = JSON.decode = JSON.stringify;
JSON.deserialize = JSON.encode = JSON.parse;
Function.prototype.proxy = Function.prototype.scope = Function.prototype.bind;

It’s common practise to abstract away from a language’s native API, just look at jQuery or any JS framework for that matter.
Don’t like it? Switch to a language where you actually have valid reasons to whine.

Comment by BenGerrissen — January 20, 2010

The fact that I put encode/decode the wrong way around, also shows that stringify/parse are more unambiguous than the other method names suggested here as well…

Comment by BenGerrissen — January 20, 2010

timdown,

“Function.prototype.bind should be verboten” because it’s different to jQuery convention?

Did you read my comment, or just scan it for things that didn’t seem right? Because I was pointing out that Function.prototype.bind should be verboten according to the logic of using JSON.stringify for “backwards compatibility” with a library that is not part of the core language at all. If JSON.serialize needed to be JSON.stringify for “backwards compatibility” with existing JSON libraries, then Function.prototype.bind can’t be used because it is impossible for it to be “backwards compatible” with existing libraries implementing a bind method.

You’ll note I think all this logic is wrongheaded, and that API naming should be based on clarity of meaning, not what market leaders do. I noted one case in which “stringify” isn’t clear but “serialize” is, and I also noted that a native JSON object is unneeded.

Its API is not perfect and I see no reason why its conventions should be applied to the language specification.

Indeed. Likewise json2.js.

* * *

BenGerrissen,

Just fix it yourself in your libraries…

There is no way to fix the JSON mistake in your libraries, if you believe that it is incorrect to have a native JSON object and that its methods should rightly be part of the Object and String prototypes (or some other, equally disruptive solution to implement in code rather than the engine). I mean, it’s “possible” to add the methods to those prototypes and to delete the JSON object (assuming access to the global object), but it will break quite a lot of existing code. So much for “backwards compatibility”, eh?

Don’t like it? Switch to a language where you actually have valid reasons to whine.

When I’m benevolent dictator of the universe, I’m going to make it a capital crime to tell people that they should go away instead of complaining. ECMAScript 5 isn’t perfect, and there are valid reasons to complain. I’ve covered but a few. If you don’t like complaints, don’t read them. Javascript is my preferred language, which is why I’m on guard when it is changed. I shouldn’t need to defend my complaints by stating my preference, but there it is.

The fact that I put encode/decode the wrong way around

I don’t really understand this, even though several people have expressed it. Encode means to convert something operable to “code”, and decode means to convert something from that “code” to something operable. It’s quite literal about what it does. “Parse” is also more or less literal about what it does. “Stringify” is not even a word, much less one that is literal about what it does: there’s no reason it couldn’t mean “convert object’s invalid property values to strings as they would be represented in JSON”, as I noted in my earlier comment.

* * *

Overall, I have no major qualms with the ECMAScript 5 specification. I think the reasoning behind rejecting a better float standard was wrong, but it only affects me in theory really. I think the reasoning behind using certain libraries’ method naming for “backwards compatibility” is wrong, but I’ll get over it eventually. I don’t really think ES5 adds a lot of value, but it wasn’t really meant to. Overall, it’s a minor update to ES3. That’s fine. But poor reasoning should be called out, because it will affect the standard process moving forward with Harmony, which will eventually see major overhauls.

Comment by eyelidlessness — January 20, 2010

@eyelidnlessness
To quote myself a few comments earlier:

Only Ajaxerex bashed Crockford, the rest simply makes a valid point.
.
To me, “stringify” is simply too cute… yuk

I am simply glad it’s there and comming, could be named better I agree, but if it’s something to trip over? JS is great at mitigation or creating more preferred aliases and most JS devs kinda learned to cope with methods being differently named (attachEvent vs addEventListener vs click vs bind vs live vs whatever). Which kinda constitutes the fact.. you can’t please everyone, they want it different anyways.
.
The important thing is, it’s comming.
.

When I’m benevolent dictator of the universe, I’m going to make it a capital crime to tell people that they should go away instead of complaining.

Typical, people who feel threatened in their freedom of speech, always imagine a world where they can restrict freedom of speech. =P Neither did I tell you to go away or that you’re not entitled to an opinion, I merely adviced what *people* can do when *people* get too frustrated or angry about something trivial. Don’t drag me down into your pit of insecurity and low self esteem, thank you very much.
.
Note to self, use more smileys so people don’t assume too much about context =) =) =) =) =)

Comment by BenGerrissen — January 20, 2010

\o/ for typos in formatting…

Comment by BenGerrissen — January 20, 2010

Typical, people who feel threatened in their freedom of speech, always imagine a world where they can restrict freedom of speech.

It’s a joke son, I say, a joke. You can tell because, you know, it was so absurd.

Neither did I tell you to go away or that you’re not entitled to an opinion

You are lying. You said, “Don’t like it? Switch to a language where you actually have valid reasons to whine.” By saying that, you’re saying that the opinion is invalid, and that those holding that opinion should switch to another language—to go away, rather than expressing the opinion.

I merely adviced what *people* can do when *people* get too frustrated or angry about something trivial.

Oh, please. I live in Seattle, passive-aggression is so old here it’s rotting.

And while it may be trivial to you, it may not to others. As Douglas Crockford (har!) says, changing a standard is an act of violence.

Don’t drag me down into your pit of insecurity and low self esteem, thank you very much.

Huh? My mommy says I’m special. Anyhow, spare me the armchair psych.

Comment by eyelidlessness — January 20, 2010

“stringify” is a lisp/scheme cultural thing. Javascript is based on scheme. “serialize” is a java thing. Which you prefer rather depends on which programming subculture you come from. There’s lots of programming words that aren’t really words.
.
” I mean, it’s “possible” to add the methods to those prototypes and to delete the JSON object (assuming access to the global object), but it will break quite a lot of existing code. So much for “backwards compatibility”, eh?”
.
Yes I suppose that if they’d done what you wanted, a lot of applications would have broken. Just as well they did what they did instead.
.
“If JSON.serialize needed to be JSON.stringify for “backwards compatibility” with existing JSON libraries, then Function.prototype.bind can’t be used because it is impossible for it to be “backwards compatible” with existing libraries implementing a bind method.”
.
prototype implements a bind method on Function.prototype which is compatible with the ecmascript version. No conflict there. jQuery implements a bind method on the jQuery.prototype object, and does not modify Function.prototype. There’s no conflict there either. jQuery’s bind does happen to do something different than Function.prototype’s bind, but neither clobbers the other so there’s actually no backwards compatibility issue here. You seem to just be grasping at straws.
.
In any case, everyone here had plenty of opportunity to complain on the ecmascript list over the past 2 years if it actually mattered to you.

Comment by Breton — January 20, 2010

@eyelidness o.O I will respond with a barrage of smileys to further elaborate context. =) =) =) =) =) =)
Thank you for choosing me as a target to pee against, I feel priviledged ;)

Comment by BenGerrissen — January 20, 2010

Breton,

Which you prefer rather depends on which programming subculture you come from. There’s lots of programming words that aren’t really words.

Maybe so, but it seems the majority prefers “serialize” over “stringify”. The former is a real word, and the latter in this case wasn’t carried over from Scheme, but from json2.js.

Yes I suppose that if they’d done what you wanted, a lot of applications would have broken.

No they wouldn’t have, and that’s not what I said. Existing applications would be broken by implementing Object.prototype.toJSON in Javascript rather than natively. Implementing it natively would have no effect on existing applications.

prototype implements a bind method on Function.prototype which is compatible with the ecmascript version. No conflict there. jQuery implements a bind method on the jQuery.prototype object, and does not modify Function.prototype. There’s no conflict there either.

The conflict is that jQuery() is a function, and therefore overrides Function.prototype.bind for a purpose different from Function.prototype.bind. It is sure to create confusion. But I don’t care that they specified Function.prototype.bind, I care that their logic of “backwards compatibility” with libraries (as opposed to the specification) was applied inconsistently. If the purpose of “stringify” is “backwards compatibility” with existing JSON libraries, then they undermine this purpose by using Function.prototype.bind. I cannot imagine how this is unclear.

jQuery’s bind does happen to do something different than Function.prototype’s bind, but neither clobbers the other so there’s actually no backwards compatibility issue here.

jQuery.prototype.bind does clobber Function.prototype.bind. jQuery inherits from Function.prototype, and overwrites the bind method. If existing library implementations’ naming conventions are to be respected (as with JSON), then they failed to apply this logic to Function.prototype.bind.

In any case, everyone here had plenty of opportunity to complain on the ecmascript list over the past 2 years if it actually mattered to you.

This is as useful as BenGerrissen’s “Don’t like it? Switch to a language where you actually have valid reasons to whine.” Anyhow, as great as Javascript is, ECMA has proven their inability to consider valid criticism and find working solutions: 0.1 + 0.2 = 0.30000000000000004. And criticism here or anywhere else doesn’t become invalid simply because ECMA made final decisions on the “fifth” version of ECMA-262.

I don’t really understand why anyone is so offended by criticism… as that is how standards (or anything) improve. But if you don’t like criticism, you don’t need to read it. You’re certainly not making it go away by dismissing it. (Your earlier challenges to my logic are not being addressed here, only your last comment.)

* * *

BenGerrissen,

Thank you for choosing me as a target to pee against, I feel priviledged

I don’t feel that I “peed against” you, I simply responded to the things you said—and more than that, clarified the things I had said earlier. Attaching emoticons to statements does not necessarily remove weight from those statements, and while I understand that you were being somewhat lighthearted (and I’ll clarify that I was too [insert emoticons here]), I think the dialogue itself has merit and was worth addressing.

Take none of what I said at any point as attacks on you, but rather as challenges to your opinions. I think challenging opinions is valuable. If you don’t, I’m sorry, but you should be aware that expressing your opinions will probably attract responses.

Comment by eyelidlessness — January 20, 2010

“The conflict is that jQuery() is a function, and therefore overrides Function.prototype.bind for a purpose different from Function.prototype.bind.”
.
Bzzzt. Absolutely incorrect. jQuery is a function, jQuery() is a function invocation that returns a jQuery object, on which you would find the bind method, and which does not inherit from Function.
.
Good try though.

Comment by Breton — January 20, 2010

“This is as useful as BenGerrissen’s “Don’t like it? Switch to a language where you actually have valid reasons to whine.” Anyhow, as great as Javascript is, ECMA has proven their inability to consider valid criticism and find working solutions: 0.1 + 0.2 = 0.30000000000000004. And criticism here or anywhere else doesn’t become invalid simply because ECMA made final decisions on the “fifth” version of ECMA-262.”
.
If you go there now maybe you can get your rants in before the next version is standardized. Your complaints about Ecmascript 5 now are about as useful as a quadriplegic complaining about road laws. Maybe you can help future potential victims, but Ecmascript 5 is a done deal. You’ll never grow those nerve cells in your spine back, dude.

Comment by Breton — January 20, 2010

“Maybe so, but it seems the majority prefers “serialize” over “stringify”. The former is a real word, and the latter in this case wasn’t carried over from Scheme, but from json2.js.”

The former is a real word- in the united states. In every other english speaking country it is an infantile mispelling of serialise. Now just imagine all the english speakers of the world spelling serialise correctly, and getting a type error, undefined is not a function, and spending half an hour trying to figure out what’s wrong.

At the very least, stringify is weird enough to have one canonical spelling that everyone in the world can agree on.

Besides, you have no statistics on preferences for one or the other. That is merely an assertion on your part. Majority Shmajority.

Comment by Breton — January 20, 2010

Breton,

Bzzzt. Absolutely incorrect. jQuery is a function, jQuery() is a function invocation that returns a jQuery object, on which you would find the bind method, and which does not inherit from Function.

My first reaction was “wow, you can’t possibly be so pedantic as to misinterpret my use of parentheses to distinguish the function from the library name as the invocation result”. Then I stopped and thought, “no, that sounds right. I doubt there is actually a jQuery.bind method. I can’t believe I’ve been so wrongheaded about this.” So then I checked, to be sure. And there is a jQuery.bind method.

console.log(jQuery.bind); // function() {...

So I’m back to… wow, you can’t possibly be so pedantic. But apparently you can. jQuery.bind overwrites Function.prototype.bind in ES5.

If you go there now maybe you can get your rants in before the next version is standardized.

What difference would it have made? If IBM didn’t have enough weight to get the change in, how would little, insignificant me at http://null/ have tipped the scales?

Your complaints about Ecmascript 5 now are about as useful as a quadriplegic complaining about road laws. Maybe you can help future potential victims, but Ecmascript 5 is a done deal. You’ll never grow those nerve cells in your spine back, dude.

Needless to say, I don’t agree. Many, many people who have influence on Javascript read (and write for) this site. I think public opposition to mistakes will help to pressure ECMA to avoid repeating those mistakes. If you disagree, feel free to ignore me.

The former is a real word- in the united states. In every other english speaking country it is an infantile mispelling of serialise.

Oh, more pedantry. Well, I don’t care to debate the merits of “correct” spellings between American English and other English dialects (my position, for what it’s worth, is that neither is “more” or “less” correct). But I will point out that they are the same word, spelt differently. Words are symbols for concepts and entities, not meaningless collections of letter-shaped symbols. It is a real word, whether it contains a z or an s.

I prefer for a language to be consistent with its naming conventions. I’m only aware of one native Javascript component that differs between American and non-American English, the Math object. So I would expect any native appearance of the word “serialize” to take the American English spelling. Otherwise, I wouldn’t care which was implemented.

And not that ECMA should let the DOM specifications influence spelling, but where Javascript does interact with the DOM, spellings are entirely American where there is any potential conflict.

Nearly all programming languages favor American English. In fact, I can’t think of any localized to non-American English.

With all of that said…

Now just imagine all the english speakers of the world spelling serialise correctly, and getting a type error, undefined is not a function, and spending half an hour trying to figure out what’s wrong.

I sincerely doubt this would happen too often. “Serialize” is used in many languages… I’m not aware of any using “serialise”.

At the very least, stringify is weird enough to have one canonical spelling that everyone in the world can agree on.

This is a really poor reason to choose any particular name for anything. “Everyone in the world” is obviously limited to English speakers, which is quite obviously not everyone in the world (and a shrinking proportion of the programming profession). By your logic, we should do away with any human language-based naming and adopt symbols that have no localized meaning whatever.

Besides, you have no statistics on preferences for one or the other. That is merely an assertion on your part. Majority Shmajority.

While I have no idea how you can know this, you’re right. I have no hard data. I was stating an observation.

Comment by eyelidlessness — January 20, 2010

I thought you would check, so I checked myself before I posted. This was my result:
console.log(jQuery.bind); //undefined

I think maybe you should double check your work.

“What difference would it have made? If IBM didn’t have enough weight to get the change in, how would little, insignificant me at http://null/ have tipped the scales?”

You obviously have no concept of exactly how hard they tried to satisfy IBM’s demand. Fixing that problem is way more difficult than you seem to think, and they simply ran out of time, so rather than standardise an even more broken and awkward version of ecmascript, they decided to put it off until the next version. If you have some brilliant idea of how to make it work, I can gaurantee that everyone on the committee is eager to hear it.
.
“Needless to say, I don’t agree. Many, many people who have influence on Javascript read (and write for) this site. I think public opposition to mistakes will help to pressure ECMA to avoid repeating those mistakes. If you disagree, feel free to ignore me.”
.
And you can contact the people that have influence on the standard directly, via the ecmascript list, without having to go through these passive agressive indirect routes where you expect them to come to you.
.
“This is a really poor reason to choose any particular name for anything. “Everyone in the world” is obviously limited to English speakers, which is quite obviously not everyone in the world (and a shrinking proportion of the programming profession). By your logic, we should do away with any human language-based naming and adopt symbols that have no localized meaning whatever.”
.
Non english speakers program in javascript too. There are no non english localized versions of javascript, at least none that I’m aware of. There is no reason why non english speakers should object to “stringify”, as it’s just as opaque and meaningless (outside the context of javascript) as any of the other javascript words.

Comment by Breton — January 20, 2010

console.log(jQuery.bind); //undefined
//check whether this is jQuery’s bind, or native bind, or prototype’s bind. Simply verifying that it is a function proves nothing.

Comment by Breton — January 20, 2010

I thought you would check, so I checked myself before I posted. This was my result:
console.log(jQuery.bind); //undefined
I think maybe you should double check your work.

So you are right. I just looked at my open tabs and checked in the first which had jQuery active. Apparently that site adds jQuery.bind at some point during runtime, no other instances I’ve checked have it. I concede this point, as well as my objection to Function.prototype.bind. I do not concede my point about treating library conventions as “backwards compatibility” for the language. While the conflict I thought I had identified turned out to be a mistake, it’s easy to see how these conflicts could arise where there are competing libraries whose “conventions” may differ.

You obviously have no concept of exactly how hard they tried to satisfy IBM’s demand.

Actually, I wasn’t really fairly representing it. IBM’s demand wasn’t for a solution to the poor float standard, but for a specific replacement that had its own problems (speed). This was part of the reason it was rejected. The other part was that, supposedly, “it would break existing applications”. I addressed this in my first comment to this post.

Fixing that problem is way more difficult than you seem to think

Douglas Crockford can rattle off a few replacement float standards that would work. It’s not that difficult, the work is done.

and they simply ran out of time

Horseshit. They had years and years and years.

so rather than standardise an even more broken and awkward version of ecmascript, they decided to put it off until the next version.

This much is true.

And you can contact the people that have influence on the standard directly, via the ecmascript list, without having to go through these passive agressive indirect routes where you expect them to come to you.

Let me be absolutely blunt. You are not going to stop me from posting on Ajaxian, in a post about ES5, what I think about ES5. If you don’t like it, you can tell me so, but it won’t stop me. You do not know if I do or do not post on the ECMAScript list, and doing so would not prevent me from expressing my opinions in other venues. And not doing so would not invalidate my opinions.

Non english speakers program in javascript too. There are no non english localized versions of javascript, at least none that I’m aware of. There is no reason why non english speakers should object to “stringify”, as it’s just as opaque and meaningless (outside the context of javascript) as any of the other javascript words.

You missed my point entirely. By saying that native objects and methods and reserved words must use spellings which “everyone in the world can agree on”, you have already eliminated every single word in the language.

Comment by eyelidlessness — January 21, 2010

HI

A great information about the new volume of Java Script and the compiler recognize the use strict directive and adapting execution according to the rules given in annex C of the ES5 specification.

http://www.bid66.com

Comment by jamesparker — January 21, 2010

“I do not concede my point about treating library conventions as “backwards compatibility” for the language. ”

I assume then that you object to the Array extras for the same reasons?

Comment by Breton — January 21, 2010

I assume then that you object to the Array extras for the same reasons?

I’m not aware of any of their names being justified based on “backwards compatibility” with libraries. If that justification was advanced for those, then yes I object to that justification in those cases as well.

I should clarify, because it’s unclear to me whether you’re aware or not, that I don’t object to the functionality of any of the ES5 additions. I object to one name (“stringify”), the unnecessary creation of the native JSON object where its methods would be better suited to the Object and String prototypes, and primarily the use of library conventions as justification for names. I don’t even object to library functionality being made part of the native standard—just treating one library’s naming conventions as if they are retroactively part of the standard.

Comment by eyelidlessness — January 21, 2010

The array extras were all adopted and compatible with the prototype library.
.
I think they’ve avoided adding anything to Object.prototype for backwards compatibility. json2.js, with the JSON object, exists for a similar but different reason. json.js did exactly as you propose, but methods added to Object.prototype are enumerable on everything that inherits from Object. Native methods can be made non-enumerable, but I think that there would still be name collisions with existing libraries, frameworks, and scripts that copied the json.js convention.

json2.js is already widely deployed, and from the start was setup in a certain way to fall back to some future native version. To deviate from that would be to either break any page that uses json2.js, or to ignore the forward compatibility built into the design of json2.js, for reasons of taste, rather than practicality. To take advantage of the improved speed of native JSON, you would force everyone to rejig their page to use the native library? to either totally rewrite their scripts, or update to some newer version of json2.js that falls back to what actually got standardised?
.
Oh well, nevermind all that. Millions of dollars in maintenance work is totally worth not being pushed around by some library author, right?

Comment by Breton — January 21, 2010

The array extras were all adopted and compatible with the prototype library.

Breton, do you have any reference about that?

Comment by igstan — January 21, 2010

seriously who gives a fuck how its named. Its works, its there and its native (soon). Stop complaining.

Comment by V1 — January 21, 2010

@eyelidlessness, jQuery breaks standards (which where defined well before jQuery was launched) all over the place (.css() .click() .hover() etc.) and thats OK, since jQuery adds convenience methods which make all our lives a lot easier.
.
JSON.js adds never before seen functionality in JS, it’s THE first library that implemented JSON, it IS THE standard before it was an official standard.
.
Standards are created on utility thats commonly and widely used and preferably, through methods already know by it’s users. Ergo ‘parse’ and ‘stringify’. Before that, there was no JSON or JSON utility.
.
Before jQuery, there already DOM methods for manipulation and jQuery steered away from that to create an abstraction that was muuuuuch easier to use.
.
So your argument is actually the other way around, imagine if ECMA suddenly changed all DOM methods, it would break jQuery. And THAT’s why the method is called ‘stringify’.
.
And I still agree, it’s not well named, but THATS the reason it is what it is. NOT the other way around. Hope I made myself clear enough and that you stop using jQuery (or any other library thats build on standards for that matter) as an example.
.
phew.

Comment by BenGerrissen — January 21, 2010

ECMA or W3C

Comment by BenGerrissen — January 21, 2010

@igstan no, I was just there as it happened. One day there was a new library, called prototype, and one of the things it had was array extras, and it was neat. Then firefox added the same array extras, so they would work faster. Then a couple other browsers added them. Then they were standardized into ecmascript 5.

I could look into it more deeply if you want real evidence.

Comment by Breton — January 21, 2010

Ah okay, the inspiration is a little bit looser than I thought.

http://www.prototypejs.org/api/enumerable

but still a lot of those methods look pretty similar.

Comment by Breton — January 21, 2010

and also
http://www.prototypejs.org/api/array

Comment by Breton — January 21, 2010

@breton, prototypejs ported, collected and added a lot to JS we take for granted now ;)

Comment by BenGerrissen — January 21, 2010

Breton,

The array extras were all adopted and compatible with the prototype library.

Let me ask again: was the justification for the naming convention of those methods that they needed to maintain “backwards compatibility” with Prototype? If so, that justification is wrong. If not, I don’t see how it’s relevant.

I think they’ve avoided adding anything to Object.prototype for backwards compatibility.

How do you figure? Adding to Object.prototype can break backwards compatibility only when adding in Javascript, not natively.

Native methods can be made non-enumerable, but I think that there would still be name collisions with existing libraries, frameworks, and scripts that copied the json.js convention.

And if that is meant to justify never adding non-enumerable native methods to Object.prototype, then its logic extends to never adding any semantics to the language whatsoever. The new native JSON object may not break json2.js, but it might break some other library or script. How can they ever know?

json2.js is already widely deployed, and from the start was setup in a certain way to fall back to some future native version. To deviate from that would be to either break any page that uses json2.js, or to ignore the forward compatibility built into the design of json2.js, for reasons of taste, rather than practicality.

Why is json2.js so special? How does ECMA determine which scripts to break and which not to break? This doesn’t make sense to me.

To take advantage of the improved speed of native JSON, you would force everyone to rejig their page to use the native library? to either totally rewrite their scripts, or update to some newer version of json2.js that falls back to what actually got standardised?

If some other naming had been adopted, it would not be hard at all for json2.js to be updated to support it. Nothing else would need to change. Yes, sometimes code needs to be updated when languages change. This is still the case even though json2.js wasn’t broken.

Oh well, nevermind all that. Millions of dollars in maintenance work is totally worth not being pushed around by some library author, right?

I’d say that when ECMAScript changes get implemented, millions of dollars in maintenance work is an inevitability. I think you’re exaggerating the consequences of breaking the single json2.js library, however.

Ah okay, the inspiration is a little bit looser than I thought.
http://www.prototypejs.org/api/enumerable
but still a lot of those methods look pretty similar.

and also
http://www.prototypejs.org/api/array

Only one of the Array extras methods appears (at least by the same name) under Enumerable (and two under Array). Hardly analogous to the claim that JSON methods must maintain the naming of json2.js for “backwards compatibility” with that library.

* * *

V1,

seriously who gives a fuck how its named.

I do. But more importantly, I give a fuck about why it’s named what it’s named.

Stop complaining.

No. Why is it that so many people insist on complaining about people complaining, insisting that those people stop complaining? Is it like… some kind of a competition to see who can be the most hypocritical by saying exactly the same thing? Uphill battle, my friend. If you don’t like my complaints, or the fact that I’m complaining, feel free to ignore me. I will not stop complaining because you don’t like it.

* * *

BenGerrissen,

jQuery breaks standards (which where defined well before jQuery was launched) all over the place (.css() .click() .hover() etc.) and thats OK, since jQuery adds convenience methods which make all our lives a lot easier.

jQuery isn’t “breaking standards” by providing convenience methods. Those standards still work. I don’t see how this is relevant.

JSON.js adds never before seen functionality in JS, it’s THE first library that implemented JSON, it IS THE standard before it was an official standard.

You may be right. But json.js was not the basis of the ES5 JSON standard, json2.js was.

Standards are created on utility thats commonly and widely used and preferably, through methods already know by it’s users. Ergo ‘parse’ and ’stringify’. Before that, there was no JSON or JSON utility.

Parse and stringify did not appear in json.js, which came before json2.js. Your argument is incorrect.

I agree that standards are (or ought to be) created on common-use utility. I don’t think that carries over to naming conventions necessarily, and I certainly don’t think that it’s right for ECMA (or any other standards organization) to treat user code as if it’s retroactively part of the standard—to refer to json2.js or prototype.js or jQuery or any other library as if it is part of the ECMA-262 standard and therefore a source of “backwards compatibility”.

Before jQuery, there already DOM methods for manipulation and jQuery steered away from that to create an abstraction that was muuuuuch easier to use.

And so did Prototype. And Mootools. And a bunch of other libraries. All of which conflict. Which becomes retroactively part of the standard and a target of “backwards compatibility”, and which get broken or neglected?

So your argument is actually the other way around, imagine if ECMA suddenly changed all DOM methods, it would break jQuery.

ECMA doesn’t have any control over the DOM. And changing existing native methods (ECMA-262 or DOM) is not analogous to inventing whole new native objects and methods, which is what was done with JSON.

And THAT’s why the method is called ’stringify’.

How the hell do you figure? There was never a JSON.stringify (or a JSON object) in ECMA-262 before.

Hope I made myself clear enough and that you stop using jQuery (or any other library thats build on standards for that matter) as an example.

You’ve made your argument clear (it was never unclear), but it’s still wrong. And why would I stop using jQuery or any other library? It has nothing to do with this discussion.

prototypejs ported, collected and added a lot to JS we take for granted now

Agreed. And truth be told, I’d probably still prefer Prototype over jQuery if it weren’t for the fact that Prototype has stagnated while jQuery has progressed and become the de facto standard DOM library.

Comment by eyelidlessness — January 21, 2010

“How can you be right – when you disagree with me?”

Comment by rasmusfl0e — January 21, 2010

@rasmusfl0e I went to your site, and I thought it was broken in firefox. I was going to warn you about it. But then I realized that your site’s navigation is just confusing and inscrutable. If you have a page saying “This is my work, have a look!”, and all I can see are two squares with diagonal lines through them, I have to tell you it’s damn baffling. I didn’t think to look and see that the navigation was changed. The change was not very obvious- since there’s no visual hierarchy it didn’t seem as though it had changed at all until I happen to look and watch very carefully as I clicked through the site.

@eyelidlessness
When new browsers that support native json fully replace old browsers that don’t, it would be nice to just simply get rid of json2.js so that users don’t have to download it anymore, and I don’t have to rewrite my whole site.

Comment by Breton — January 22, 2010

@Breton: Thank you for the I-thought-it-was-broken-but-it-apparently-wasn’t-warning, Breton :)

Comment by rasmusfl0e — January 22, 2010

Great i love it!

Comment by Aphrodisiac — January 22, 2010

Breton,

When new browsers that support native json fully replace old browsers that don’t, it would be nice to just simply get rid of json2.js so that users don’t have to download it anymore, and I don’t have to rewrite my whole site.

I think you’ve demonstrated that you’re competent enough to know that you wouldn’t have to rewrite your whole site if the spec’s naming had not been based on json2.js, and also to know that your argument doesn’t hold water for sites using JSON libraries besides json2.js, and also to know that it will be years before you can safely remove json2.js and expect all of your users to be able to use the native functionality. I think it’s you grasping at straws.

If you disagree with my premise—that it is unwise to treat favored libraries as retroactively part of the standard—argue against that point. What you’re arguing here is largely irrelevant and based on emotional appeal that doesn’t stand up to much scrutiny.

Comment by eyelidlessness — January 22, 2010

@eyelidlessness:
Re. your “Did you read my comment, or just scan it for things that didn’t seem right?” For what it’s worth now, yes, I think that phrase just stuck out at me and I didn’t read the context correctly.

Comment by timdown — January 25, 2010

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.