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)
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
