[[OwnPropertyKeys]] key ordering
allen at wirfs-brock.com
Sat Apr 19 13:21:56 PDT 2014
On Apr 19, 2014, at 11:14 AM, Allen Wirfs-Brock wrote:
> 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?
I need to update item 1) above as follows because "array index" is implies 32-bit value:
1) All integer index property keys, in ascending numeric order. Followed by...
where integer index is defined as "An integer index is String-valued property key that is a canonical numeric string (see 7.1.16) and whose numeric value is either +0 or a positive integer."
and canonical numeric string is defined at http://people.mozilla.org/~jorendorff/es6-draft.html#sec-canonicalnumericstring
Definition includes integer values that exceed the Uint32 limit or the actual length of an Array object.
Negative integers, including "-0" if it actually exists as a property key are not included in this first sublist.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss