Jesse McCarthy (2015-08-22T16:47:43.000Z)
Meant to send this to the list originally...

----- Original Message ----- 
From: "Jesse McCarthy" <es-discuss-2015-02 at jessemccarthy.net>
To: "Allen Wirfs-Brock" <allen at wirfs-brock.com>
Sent: Friday, August 21, 2015 4:12 PM
Subject: Re: Property ordering of [[Enumerate]] / getOwnPropertyNames()


> Re: my previous message...sorry, not `Object.ownKeys()`, obviously that's 
> not a sensible name. `Object.keys()` is already own keys. What I mean is 
> some function that bridges the gap that I mentioned (return enumerable 
> keys in `[[OwnPropertyKeys]]` order. Or in other words, `7.3.21 
> EnumerableOwnNames (O)` without step #6.) Not sure of a sensible name off 
> the top of my head, not that it matters.
>
> ~Jesse
>
> ----- Original Message ----- 
> From: "Allen Wirfs-Brock" <allen at wirfs-brock.com>
> To: "Jesse McCarthy" <es-discuss-2015-02 at jessemccarthy.net>
> Cc: <es-discuss at mozilla.org>
> Sent: Thursday, August 20, 2015 8:40 PM
> Subject: Re: Property ordering of [[Enumerate]] / getOwnPropertyNames()
>
>
>
> 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 at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
d at domenic.me (2015-09-02T20:24:59.021Z)
(duplicate post)