4 ms·

Yes, this is because the JS spec requires that object keys are iterated in insertion order (with a bizarre exception for arrays).

vanderZwan 9y ago
Ah, I guess that explains it. Although that does not require the engine to have under-the-hood layout respect that, does it? They could just as easily choose to keep the memory layout in the same order. 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" ] PS: Thanks for making a great shell :)
- sayrer 9y ago
  Prior to Chrome's release, browsers preserved insertion order for numeric keys as well (but this was not in the ES3 spec). 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.
deathanatos 9y ago
TIL. For those like me for which this is new, this was apparently a change in the ES 2015 / ES 6 version of the standard. See: https://stackoverflow.com/questions/5525795/does-javascript-guarantee-object-property-order/38218582#38218582 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.)
- vanderZwan 9y ago
  I feel so justified in adding this guard in my compression pre-processor[0] code, even though I never had a bug without it: // the keys of an object export function keysOf(obj) { let keys = Object.keys(obj); keys.sort(); return oneOf(keys); } Context: the rest of the code takes an object representing a schema, and creates two functions. One that can turn any object fitting that schema into an array, with positions indicating which key they originally belonged to, and another one that can reverse the process. 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/client/js/state-compressor.js#[L205-L210] https://github.com/linnarsson-lab/loom-viewer/blob/master/cl... [1] https://github.com/linnarsson-lab/loom-viewer/blob/master/client/js/util.js#[L807-L870] https://github.com/linnarsson-lab/loom-viewer/blob/master/cl...
pdpi 9y ago
Wait what? Since when? That wasn’t the case at all 5 or 6 years ago (I got bitten in the arse by Rhino not implementing it that way)
- deleted 9y ago
  [deleted]
- epmatsw 9y ago
  Most browsers already did, and some (not all) of the ES2015 stuff requires property ordering. Probably easier to just keep everything ordered since it could be needed by those methods.

vanderZwan 9y ago

Ah, I guess that explains it. Although that does not require the engine to have under-the-hood layout respect that, does it? They could just as easily choose to keep the memory layout in the same order. 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" ] PS: Thanks for making a great shell :)

sayrer 9y ago
Prior to Chrome's release, browsers preserved insertion order for numeric keys as well (but this was not in the ES3 spec). 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.

deathanatos 9y ago

TIL. For those like me for which this is new, this was apparently a change in the ES 2015 / ES 6 version of the standard. See: https://stackoverflow.com/questions/5525795/does-javascript-guarantee-object-property-order/38218582#38218582 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.)

vanderZwan 9y ago
I feel so justified in adding this guard in my compression pre-processor[0] code, even though I never had a bug without it: // the keys of an object export function keysOf(obj) { let keys = Object.keys(obj); keys.sort(); return oneOf(keys); } Context: the rest of the code takes an object representing a schema, and creates two functions. One that can turn any object fitting that schema into an array, with positions indicating which key they originally belonged to, and another one that can reverse the process. 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/client/js/state-compressor.js#[L205-L210] https://github.com/linnarsson-lab/loom-viewer/blob/master/cl... [1] https://github.com/linnarsson-lab/loom-viewer/blob/master/client/js/util.js#[L807-L870] https://github.com/linnarsson-lab/loom-viewer/blob/master/cl...

pdpi 9y ago

Wait what? Since when? That wasn’t the case at all 5 or 6 years ago (I got bitten in the arse by Rhino not implementing it that way)

deleted 9y ago
[deleted]
epmatsw 9y ago
Most browsers already did, and some (not all) of the ES2015 stuff requires property ordering. Probably easier to just keep everything ordered since it could be needed by those methods.