Property ordering of [[Enumerate]] / getOwnPropertyNames()

Allen Wirfs-Brock allen at
Thu Sep 3 03:21:32 UTC 2015

On Sep 2, 2015, at 4:10 PM, John-David Dalton wrote:

> Hiya,
> > [Enumerate]] must obtain the own property keys of the target object as if by calling its [[OwnPropertyKeys]] internal method
> Whoa that's tricky language. I assumed reading it that [[Enumerable]] was to follow the order of [[OwnPropertyKeys]] (as part of "as if by") and walking the prototype chain.

It says "obtain", not "obtain and order".  In other words,  the initial set of own properties of the target object must include the same set of keys as provided by [[OwnPropertyKeys]] but the order in which they are processed need not be the same.  Why?  Because TCD39 was not yet willing to mandate a for-in enumeration order.

> It's odd to me that:
>   Reflect.ownKeys() has defined order but
>   Reflect.enumerate() doesn't

Note that [[OwnPropertyKeys]] returns any array whose property ordering is fixed when it is returned.
[[Enumerate]] returns an iterator, and the property state of the object that is  being iterated over can change between calls to `next1.  That's the big difference.

> I'm using Reflect.enumerate() to create a `keysIn` implementation (like `keys` but for own & inherited key names).
> :+1: for more defined behavior in ES7.

me too


More information about the es-discuss mailing list