[[OwnPropertyKeys]] key ordering

Allen Wirfs-Brock allen at wirfs-brock.com
Sat Apr 19 11:14:00 PDT 2014

I'm in the middle of updating the spec. of [[OwnPropertyKeys]] to returns an Array rather than an Iterator. While doing this I realized that because [[OwnPropertyKeys]] is essentially a new MOP level operation we have the opportunity to precisely define the property key ordering it exposes for ordinary objects. This seems like a one-time opportunity that we shouldn't pass up.

Note that this doesn't necessarily mean we need to change the unspecified/weakly specified ordering of exiting library functions such as Object.keys (even though they are specified in terms of [[OwnPropertyKeys]]).  But it does mean that new library functions such as Reflect.ownKeys will be defined with a fully specified specified ordering.

The ordering I propose is:
1) All array index property keys, in ascending array index numeric order. Followed by:
2) All other string property keys, in property creation order. Followed by:
3) All symbol property keys, in property creation order

Does anybody see any reason why we shouldn't specify (this) property ordering? 


More information about the es-discuss mailing list