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 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" <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
