4

Possible Duplicate:
Chrome and probably Opera sort object properties automatically

I have a very simple code:

var obj = {3:'a',2:'b',1:'c'};
console.log(obj);

In Firefox 4.0.1 it returns:

Object { 3="a", 2="b", 1="c"}

In Chrome 11.0.696.71 it returns:

Object { 1="c", 2="b", 3="a"}

How can I coerce Chrome doesn't sort this object?

Community
  • 1
  • 1
Alex Pliutau
  • 21,392
  • 27
  • 113
  • 143

2 Answers2

4

For Objects the spec is that the order of elements is not preserved. In other words javascript doesn't guarantee any particular order for the properties of an Object.

You'll have to use an array if you want to preserve the order of elements. In this case, your Object can be rewritten to:

var arrobj = ['c','b','a'];

or

var arrobj = ['a','b','c'].reverse();

Where you have take into account that the first element index will be 0 (zero)

KooiInc
  • 119,216
  • 31
  • 141
  • 177
  • Nope. Array numbering starts at `0`. As the OP wants to use specific keys, he'd better use `var arr[3] = "a", arr[2] = "b", arr[1] = "c";` – Marcel Korpel May 29 '11 at 09:47
  • Javascript doesn't have associative arrays, it has objects. – RobG May 29 '11 at 10:56
  • @Marcel: Well, he could also use ['-','c','b','a'] or when iterating through the array add 1 to the iterator etc. Many roads lead to Rome here. The essence is: property order is not preserved in javascript objects. @RobG: I know. It looked like the OP would understand the term associative arrays better. Ditched it. – KooiInc May 29 '11 at 11:06
3

It's a known "bug"/feature of chrome. Even author of jQuery indignant of this, but chrome guys stay inflexible, saying that this is a "feature": http://code.google.com/p/chromium/issues/detail?id=883 [1]

As a workaround use arrays or some kind of MixedCollection (as in extjs) or something similar.

null !== true and also null !== false // in php and js it's so

[1]: John Resig (jeresig) is an author of jquery

gaRex
  • 4,144
  • 25
  • 37
  • 4
    -1 for rant on Chrome developers, order of object's properties is and will remain unspecified; +1 for recommendation of arrays. – Marcel Korpel May 29 '11 at 09:32
  • It was unspecified, but all other browsers already implement it as unordered. So it too formal and also breaks older code. I think here chrome developers was as burocrats -- too formal. – gaRex May 29 '11 at 09:41
  • I'm sorry, I don't understand what you're saying: you just admitted that “all other browsers already implement it as unordered”; this just means you shouldn't rely on the order of the properties. Code relying on this is simply broken. BTW, which “older code” do you mean? – Marcel Korpel May 29 '11 at 09:44
  • 6
    It's not a bug; the JavaScript specification does not stipulate any order for object elements, so it's entirely dependent on the implementation and a particular behaviour shouldn't be expected. – Will Vousden May 29 '11 at 09:44
  • I'm not state, that this is a bug -- it's a "bug". Other browsers before chrome save order, even it was'n in specs. Chrome just breaks this tradition. This discussion may be better should be in programmers.se -- not here. – gaRex May 29 '11 at 10:27
  • Unspecified !== do as you want. Same as null != false – gaRex May 29 '11 at 10:32
  • Umm..."unspecified" actually *is* "do as you want". It specifically means that there is no requirement one way or another, and any way you do it is correct (as long as it fulfills all of the other requirements). What's broken is any code that relies on it meaning "do as you want, as long as you do it the way everyone else does". – cHao May 30 '11 at 12:09
  • Hmm... So if it's unspecified, that killing people by big red knife is evil, you will go and will do it? :) – gaRex May 30 '11 at 12:38
  • @cHao, btw, does true === null or false === null? It's a choice of a good or not so good designer. It's not a robotic's math -- it's a human mind. – gaRex May 30 '11 at 13:10
  • @gaRex: it's pretty well specified (by law, by just about every religion) that killing people at all is evil. If it weren't, i'd do what i felt like doing. :) – cHao May 30 '11 at 16:49
  • 2
    @gaRex: As for the true/false/null stuff, i'm not sure what you're getting at there. A few "clever" people made assumptions that should never have been made, because the language spec explicitly says they should never have been made, and now their code is broken because of it. I have no pity for them. And i have no problem with Chrome's choices, as every bit of JS that didn't make those boneheaded assumptions still works fine. – cHao May 30 '11 at 17:13
  • Anyway it's a holywar and I'm on the side of those, who like traditions and uderstand what is "breaking of production code". I hope ECMA will specify it and chrome will fix this "bug". https://mail.mozilla.org/pipermail/es-discuss/2011-March/012965.html – gaRex May 30 '11 at 20:25