Tab Atkins Jr. schrieb:
On Wed, Apr 15, 2015 at 6:39 PM, <a.d.be...@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]]
order then?
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`)?
Bergi
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
