Yes, this is because the JS spec requires that object keys are iterated in insertion order (with a bizarre exception for arrays).
Although I suppose you're already required to have two separate hidden classes to distinguish these two kinds of objects anyway.
> with a bizarre exception for arrays
Wow, you weren't joking with how bizarre this gets:
var a = {};
var b = {};
a.a = 0;
a.b = 1;
a[0] = 0;
a[1] = 1;
b.b = 1;
b.a = 0;
b[1] = 1;
b[0] = 0;
Object.keys(a); // Array [ "0", "1", "a", "b" ]
Object.keys(b); // Array [ "0", "1", "b", "a" ]
Chrome/V8's team found they could get substantial performance improvements by diverging from the de facto standard, without too much of a cost to web compatibility.
See: https://stackoverflow.com/questions/5525795/does-javascript-...
The order is only sometimes guaranteed, of course, because JavaScript. (But critically, for this discussion, it is important that it is sometimes guaranteed, because it forces that information to be stored by the VM.)
// the keys of an object
export function keysOf(obj) {
let keys = Object.keys(obj);
keys.sort();
return oneOf(keys);
}
Could this also explain why I have no consistent order of properties when viewing state with the Redux dev-tools? Instead of Object.assign I use my own simplified merge code[1]. Maybe if I also make that use a sorted set of keys, the devtools will become more consistent in their presentation (and it might result in more consistent hidden classes too).
[0] https://github.com/linnarsson-lab/loom-viewer/blob/master/cl...
[1] https://github.com/linnarsson-lab/loom-viewer/blob/master/cl...