Property ordering of [[Enumerate]] / getOwnPropertyNames()
allen at wirfs-brock.com
Thu Sep 3 03:21:32 UTC 2015
On Sep 2, 2015, at 4:10 PM, John-David Dalton wrote:
> > [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.
More information about the es-discuss