Object.keys(): Why no inherited properties?

[Dmitry Soshnikov]

On 08.09.2011 20:16, Allen Wirfs-Brock wrote:
> On Sep 7, 2011, at 11:27 AM, Dmitry Soshnikov wrote:
>
>> On 07.09.2011 20:53, Brendan Eich wrote:
>>> On Sep 7, 2011, at 9:29 AM, Dmitry Soshnikov wrote:
>>>
>>>> On 07.09.2011 19:33, Felipe Gasper wrote:
>>>>> Why does Object.keys() not allow, as an option, iterating through inherited properties?
>>>>>
>>>> Because it's the same version that is from Prototype.js. I guess it was ported "as is" for compatibility with the library. But IMO, yes, native implementation could provide at least an option for this case (if needed).
>>> If you mean that an ES5-conforming implementation could add an optional boolean parameter to Object.keys, to get inherited enumerable properties too, then please, no: that is against the NOTE in Clause 15 (quoting from ES5.1):
>>>
>> No, I just explained from where the roots of Object.keys() -- from Prototype.js. It was just ported "as is", though, IMO, when it was porting, it with the same success could accept this additional parameter. And I assumed that it was ported as is only because to support compatibility with the Prototype.js.
>
> Nice theory, but not the way it actually went down. We wanted to provide a function for use in application code that was guaranteed to order the own property names of an object in the same implementation specific order used by  for-in. Use in conjunction with the "Array extras" was contemplated. For simple "flat" collections of properties we want to enabling enumerating over them using the array functions instead of for-in but also to ensure that the processing order would be the same regardless of which technique was used.
>

Maybe it was also mentioned as a reason in that discussion. Though, I 
don't see a big practical usage of this (perhaps maybe except of only 
convenience in some functional programming cases; e.g. when you need to 
pass the property names aka "keys" to some function which will enumerate 
them). In real practical examples it's just inefficient to collent the 
properties first and the to go over them via `forEach` of arrays. Simple 
`for-in` is enough.

I would better implemented then `Object.forEach` or `Object.forAll` 
higher-order functions.

> It was thought of as a application layer function rather than as a reflection function.  That was why it was given a simple, short name rather than being called something like getOwnEnumerablePropertyNames.

Sure.

>    I believe that Crockford suggested the name

No, maybe Crockford just gave the publicity on meetings, but clearly the 
method was borrowed from Prototype.js.

What's the most funny in this story is that Prototype.js borrowed the 
method from Ruby (actually, Prototype.js initially was written only for 
Ruby on Rails framework). The whole library is inspired by the Ruby and 
the idea of monkey-patching -- this is why Prototype.js augments 
built-ins: Array.prototype, String.prototype, etc (Rails uses this 
technique heavily also).

Unfortunately, authors of Prototype.js couldn't augment 
`Object.prototype` because the library was developed in the times of 
ES3-only -- that is, they cannot control `enumerable` (DontEnum) 
attribute there. However, if the had such an ability it's clear 100% 
that the method `keys` would be an _instance_ method, the same as it is 
in Ruby.

Ruby:

foo = {:x => 10, :y => 20}
print foo.keys # [:x, :y]

The other thing to note, that JS in contrast with Ruby doesn't have 
concept of a "key" (all of them are "properties"). In Ruby these two 
entities are separated: keys are accessed by the square bracket 
notation, and properties via dot-notation (the same separation by the 
way in Python).

So the thing is that the terminology, implementation, etc are borrowed 
from Ruby, but it doesn't correlates with JS terminology. OTOH, who 
cares about terminology much if the method is useful? That's why it's 
borrowed and standardized as it's standardized. Moreover, since we have 
a "virtual" concept of an "array index", then we have the same "virtual" 
concept of a "key" as "own enumerable property". So everythings fine 
here, and regarding initial letter "why not to have a flag to get 
inherited properties" -- it's also from Ruby and handled there in the 
same way -- for `foo.methods` method (own methods) and 
foo.instance_methods(true) -- including inherited.


>   but it might have been someone else.

Initially -- authors of Prototype.js, borrowing form Ruby. But I don't 
know -- maybe it was Crockford on the meetings as you mention. Anyway, 
it doesn't matter much.

>    "keys" was an obvious name choice as we were thinking about operating on objects that represented collections of key/value pairs.
>

Yes, this is true.

Dmitry.