Nailing object property order

Bergi a.d.bergi at web.de
Thu Apr 16 16:48:30 UTC 2015


Scott Sauyet schrieb:

 > Do you see good reasons *not* to do it, or are you just wondering if
 > there actually were pros to this?

Oh, I can see the use cases (you've given a good example, thanks). 
Everyone needs ordered dictionaries/maps once in a while. Maybe even 
sortable ones, including `insertAt` or `insertOrderedBy(comp)` methods?

I would have loved to get another new data structure (`OrderedMap`? 
`SortableMap`?) for this purpose. What I am opposing is that objects - 
originally meant as unordered records - are now "officially" abused for 
this. I can see the argument for speccing backwards-compability, but now 
the people who were originally writing bad (implementation-dependent) 
code are supported by the spec and can claim that the end users had to 
update their browsers to ES6-compatibility, instead of needing to fix 
their bugs.

> I could even write an `isStrictlyEqual` that goes beyond
> property equality and checks key order.

That's exactly what I am fearing. If such usage takes overhand, are we 
going to get `Object.prototype.reorderKeys` at some point? (Oh, wait, 
`Object.reorderKeys` of course).
I think there should be a clear distinction between ordered and 
unordered dictionaries somewhere, with tooling supporting both versions. 
Instead of stuffing everything into objects.
How does an algorithm know whether to use `==`, `===`, `Object.is`, 
`Object.isSameOrdered`, `Object.equals`…?

Bergi

(sorry if this came off as a rant. I know it cannot/will not be changed 
any more in ES6. I'm just missing a clear strategy statement)


More information about the es-discuss mailing list