On Aug 20, 2015, at 9:54 AM, Jesse McCarthy wrote:
> I just want to confirm some things about property enumeration order of plain
> Objects. I apologize that this has probably already been discussed before,
> but it's hard to locate a clear answer. Please note that I'm solely asking
> about ES2015 spec compliance, not what's in the wild.
>
> Given:
>
> ```js
> var y = Object.create(null);
> // Note that property names are all strings.
> y.one = 1;
> y.two = 2;
> y.three = 3;
> ```
>
> This is my understanding of what's guaranteed (or not) about enumeration
> order (in the context of the example given):
>
> 1. No guarantee of order
> Anything that relies on or has property-order equivalence with
> `[[Enumerate]]` or `EnumerableOwnNames`
> 1b. for (x in y)
> 1c. Object.keys(y)
>
> This is based on the statement in 9.1.11 [[Enumerate]] () step 1:
>> The mechanics and order of enumerating the properties is not specified
>
> Although it says that...
>> [[Enumerate]] must obtain the own property keys of the target object as if
>> by calling its [[OwnPropertyKeys]] internal method.
>
> ...and `[[OwnPropertyKeys]]` specifies ordering, my reading is that
> `[[Enumerate]]` doesn't guarantee that the iterator it returns will preserve
> the order returned by `[[OwnPropertyKeys]]`.
Correct. Historically, the for-in order was not defined and there has been
variation among browser implementations in the order they produce.(and other
specifics). ES5 added Object.keys and the requirement that it should order
the keys identically to for-in. During development of both ES5 and ES6 the
possibility of defining a defining a specific for-in order was considered but
not adopted because of web legacy compatibility concerns and uncertainly about
the willingness of browsers to make changes in the ordering they currently
produce.
If we decided to specify the for-in order it would be the order produced by the
informative algorithm provided in 9.1.11.
As a step in that direction, we should consider for ES7 adding to 9.1.11
something like:
If the target object's [[Prototype]] is null, then properties have the same
relative ordering for both [[Enumerate]] and [[OwnPropertyKeys]]
>
> 2. Guarantee of insertion order (['one', 'two', 'three'])
> Object.getOwnPropertyNames(y)
yes
>
> Are those interpretations correct?
>
> Related:
> In this thread...
> https://esdiscuss.org/topic/nailing-object-property-order
>
> ...Bergi asked these pertinent questions that no one answered:
>> But why was the default object [[enumerate]] algorithm not specced to match
>> the [[OwnPropertyKeys]] order then?
>> ...
>> Shouldn't we add a guarantee to [[enumerate]] that the subset of enumerated
>> own properties comes in insertion order as well?
legacy concerns, see above and numerous historic es-discuss threads
Allen
>
> This is partly in reference to http://stackoverflow.com/a/30244410/1034448
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
