Object.keys VS Object.getOwnPropertyNames

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Sun Apr 18 07:58:18 PDT 2010

Hello Jürg,

Sunday, April 18, 2010, 6:35:50 PM, you wrote:

> I am aware that these function names are probably set in stone by
> now, but am curious to hear the reasons for their naming, as there
> seem to be many discrepancies in there, mostly:

> - The use of both 'key' and 'name' for the same thing
> - The omitting of 'get' in Object.keys

> In terms of a clean API, something along these lines would have seemed more consistent:

> Object.getKeys
> Object.getOwnKeys

Actually, the implementation of these methods isn't corresponding much
with method names.

Thus, "Object.keys" returns also only /own/
property names, but -- excluding those with [[Enumerable]] false.

And "Object.getOwnPropertyNames" does the same but including
[[Enumerable]] = false.

Moreover, as I mentioned, "keys" name has nothing with current
ECMAScript abstraction level. In contrast with other languages where
there is separation of dot -- "." -- and bracket -- "[]" -- notations
for property accessors, in ES there's no such discrimination.
Therefore, here all of them are /properties/ and there is no devision
on /keys/array indexes/properties/

So, Ruby, from which "Object.keys" was borrowed into Prototype.js
library, in this case has exactly "keys" of a /hash/ -- and this name is
acceptable. Because along with "keys" a hash also has "properties" and
"methods". But not in ES, where there are only properties.
"Object.keys" which contradicts to all other method names in ideology
and stylistics (and has nothing with previous ES specs and
implementations) in my opinion is error of the ES5 spec.

It is also relates to why term "hash" (often used to name ES
objects), /regardless that on implementation level exactly this
theoretical data structure can be used -- hash-table/ doesn't fit and
is improper -- http://bit.ly/cA3bwY

So, ES has no "keys" concept.

> As I am new to the community process of EcmaScript but strongly
> involved with the language for soon 10 years through projects like
> Scriptographer.org and Helma.org, and therefore concerned with the
> language's future, I am curious to find out more about these
> processes of the defining of the language's API and syntax.

Just two days ago the similar question has been raised, see:


More information about the es-discuss mailing list