Object.keys VS Object.getOwnPropertyNames

Dmitry Soshnikov dmitry.soshnikov at gmail.com
Tue Apr 20 10:35:18 PDT 2010


On Sun, Apr 18, 2010 at 7:15 PM, Asen Bozhilov <asen.bozhilov at gmail.com>wrote:

> Jürg Lehni 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
>>
>>
>
>
<snip>


>
> Object.getOwnKeys  ->  Object.getOwnPropertyNames
> Object.getOwnEnumKeys  -> Object.keys
>
>
> Is ES5 get idea for Object.keys by JS libraries, which use that method? For
> example Prototype.js?
>
>
Yes, and exactly from Prototype.js. And Prototype.js borrowed this method
from Ruby, because first this library was developed as addition for Ruby on
Rails framework. If you check out method names used in Prototype.js, you'll
see that they are all borrowed from Ruby (those which are not borrowed from
previously non-standardized JS extensions such as SM's forEach, map and
other methods of arrays).

But Ruby also has interesting design and method names. And if ES could make
some minor reservations (e.g. "some properties also can be named as keys" as
it has "array-index" concept which still nevertheless a string property
name), then other suggestions for method names can be made.

For example, more frequently user wants to get own property names, so there
is no need to specify it explicitly. Then could be one method for that:

getPropertyNames()

and

getPropertyNames(true) will return also all inherited method names.

or more controllable:

getPropertyNames({
  own: false,
  enumerable: [true, false]
})

to get all -- own and inherited and regardless enumerable state.

Another variation:

getPropertyNames({
  withInherited: true,
  enumerable: "both"
})

but, maybe a bit ugly because of string "both" and too verbose.

The same can be for:

getValues(...)

If to specify "keys" concept then "getPropertyNames" can be replaced with
"getKeys" or even "keys".

Because of object being the receiver can operate with delegated properties
as its own, then /extended/ descriptor can have information (besides
enumerable, configurable and so on) whether the property is /own/. Also
"property" word in this method name can be omitted because descriptor
relates only to properties.

var fooProperty = obj.getDescriptorOf("foo");

if (fooProperty.enumerable && !fooProperty.own) {
  // do something with real owner
}

Although, can be getDescriptorForOwn("foo").

You can see some examples at http://gist.github.com/367080 (regardless my
particular implementation for that; examples are at the bottom of the
source); tested in Rhino 1.73.

But all this -- just a variation. Maybe in the future the committee will
consider some of them.

Dmitry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100420/bbadc1e3/attachment.html>


More information about the es-discuss mailing list