Meant to send this to the list originally...
----- Original Message -----
From: "Jesse McCarthy" <es-discuss-2015...@jessemccarthy.net>
To: "Allen Wirfs-Brock" <al...@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" <al...@wirfs-brock.com>
To: "Jesse McCarthy" <es-discuss-2015...@jessemccarthy.net>
Cc: <es-discuss@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
