Property ordering of [[Enumerate]] / getOwnPropertyNames()
es-discuss-2015-02 at jessemccarthy.net
Sat Aug 22 16:47:43 UTC 2015
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.
> ----- 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.
>> 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'])
>> Are those interpretations correct?
>> In this thread...
>> ...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
>> This is partly in reference to
>> es-discuss mailing list
>> es-discuss at mozilla.org
More information about the es-discuss