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.

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.

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

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.

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

but still a lot of those methods look pretty similar.

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

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

Breton, do you have any reference about that?

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?