Nailing object property order
a.d.bergi at web.de
Thu Apr 16 03:13:52 UTC 2015
Tab Atkins Jr. schrieb:
> On Wed, Apr 15, 2015 at 6:39 PM, <a.d.bergi at web.de> wrote:
>> What was the motivation to pin these down in ES6?
> Because, for objects at least, all implementations used approximately
> the same order (matching the current spec), and lots of code was
> inadvertently written that depended on that ordering, and would break
> if you enumerated it in a different order. Since browsers have to
> implement this particular ordering to be web-compatible, it was
> specced as a requirement.
I see, that makes some sense at least. But why was the default object
[[enumerate]] algorithm not specced to match the [[OwnPropertyKeys]]
Most, if not all, of the codes I've seen that unfortunately depend on
this insertion-order ordering do use simple `for in` loops (sometimes
accompanied by a `obj.hasOwnProperty` check, very rarely an
`Object.prototype.hasOwnProperty.call` check). None iterated over the
`Object.keys` or even `Object.getOwnPropertyNames` array.
Shouldn't we add a guarantee to [[enumerate]] that the subset of
enumerated *own* properties comes in insertion order as well? That would
still leave open to engines how they deal with inherited properties.
Similarly, we remove step 6 ("*Order the elements of names so they are
in the same relative order as would be produced by the Iterator that
would be returned if the [[Enumerate]] internal method was invoked on
O.*") from `EnumerableOwnNames` (`Object.keys`)?
More information about the es-discuss