Object.keys VS Object.getOwnPropertyNames

Jürg Lehni lists at scratchdisk.com
Sun Apr 18 08:38:40 PDT 2010

Thank you Dmitry and Asen for clarifying.

Of course you are both right, and I realised my proposal was wrong. But I do think Object.keys should have been named Objet.getOwnKeys or Objet.getKeys at least.

I am surprised to see a general lack of a clear convention regarding naming in the additions to the core API, especially given the history of Object.keys in one of the many JS libraries out there. It would not have been very hard for Prototype to do something along these lines in a new version instead:

Object.keys = Object.getOwnKeys || function(obj) { ... }

While these new additions seem really useful and were missing so far in the language specification, it seems they were generally defined in a quite negligent way.

Another example appears to be Object.defineProperty, where all the descriptor properties default to false, making the newly added property read-only, invisible, and protected against configuration, so pretty much the opposite of anything we were ever used to from adding properties to objects in EcmaScript so far.

While I agree that for such properties, enumerable should default to false, it seems it would have been better and made for more elegant code to let the others default to true, so they only would have to be explicitly set to false when needed. Or even better, they could have been defined as their opposites, so all values could default to false like in the current specification, e.g.: writable -> readOnly, configurable -> sealed

Object.defineProperty(name, {
	value: 10,
	readOnly: true,
	sealed: true

And speaking of Object.defineProperty, is there anybody from Microsoft on this list who could explain how it was possible for them to only implement this feature for DOM nodes but not normal objects, although it is a Object generic, along with Object.getOwnPropertyDescriptor?

This really harms such language extensions, as they appear to exist, but do not function according to the specs, making ugly browser detection a necessity, and still removing the possibility to use getters / setters on the client side, with IE being the only major browser that continues to lack any of the two ways to define them (__defineGetter__ being the other way).


On 18 Apr 2010, at 15:58, Dmitry A. Soshnikov wrote:

> 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:
> https://mail.mozilla.org/pipermail/es-discuss/2010-April/010908.html
> Dmitry.

More information about the es-discuss mailing list