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 3:59 PM
Subject: Re: Property ordering of [[Enumerate]] / getOwnPropertyNames()
> Hey Allen, thanks for the info.
>
>> Correct. Historically, the for-in order was not defined...
>
> Thanks for confirming that. That was always my understanding, including
> after reading 9.1.11, but I saw someone describe a different
> interpretation in the referenced stackoverflow answer and wanted to make
> sure I wasn't misunderstanding.
>
>> If we decided to specify the for-in order it would be the order produced
>> by the informative algorithm provided in 9.1.11.
>
> Ok, thanks, that's good to know.
>
>> 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]]
>
> My gut reaction is that sounds good (though I should note that I'm not an
> implementor :)). That is the scenario where I'm most interested in the
> property order.
>
>>> 2. Guarantee of insertion order (['one', 'two', 'three'])
>>> Object.getOwnPropertyNames(y)
>
>> yes
>
> Thanks. I kind of wish there was an `Object.ownKeys()` that bridged the
> gap between `Object.keys()` and `Object.getOwnPropertyNames()`, returning
> just enumerable props with the ordering specified for
> `[[OwnPropertyKeys]]`. It's also kind of confusing that
> `Reflect.ownKeys()` isn't limited to enumerable props. If ES7 added the
> language you mentioned though, I think that would make `Object.keys()`
> behave the way I'm talking about in the null prototype scenario.
>
>> legacy concerns, see above and numerous historic es-discuss threads
>
> I don't know off the top of my head what the legacy hazard is for
> specifying an order for something that previously had unspecified order --
> I'll look for those threads if I get motivated to find out :) I do
> understand the implementor resistance consideration of course.
>
> Thanks Allen!
>
> ----- 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
>>
>
