Javascript: why Object.keys(someobject), rather than someobject.keys?

I suppose they don't want too many properties on Object.prototype since your own properties could shadow them.

The more they include, the greater the chance for conflict.

It would be very clumsy to get the keys for this object if keys was on the prototype...

var myObj: {   keys: ["j498fhfhdl89", "1084jnmzbhgi84", "jf03jbbop021gd"]};var keys = Object.prototype.keys.call(myObj);

An example of how introducing potentially shadowed properties can break code.

There seems to be some confusion as to why it's a big deal to add new properties to Object.prototype.

It's not at all difficult to conceive of a bit of code in existence that looks like this...

if (someObject.keys) {    someObject.keys.push("new value")else    someObject.keys = ["initial value"]

Clearly this code would break if you add a keys function to Object.prototype. The fact that someObject.keys would now be a shadowing property breaks the code that is written to assume that it is not a shadowing property.

Hindsight is 20/20

If you're wondering why keys wasn't part of the original language, so that people would at least be accustomed to coding around it... well I guess they didn't find it necessary, or simply didn't think of it.

There are many possible methods and syntax features that aren't included in the language. That's why we have revisions to the specification, in order to add new features. For example, Array.prototype.forEach is a late addition. But they could add it to Array.prototype, because it doesn't break proper uses of Array.

It's not a realistic expectation that a language should include every possible feature in its 1.0 release.

Since Object.keys does nothing more than return an Array of an Object's enumerable own properties, it's a non-essential addition, that could be achieved with existing language features. It should be no surprise that it wasn't present earlier.

Conclusion

Adding keys to Object.prototype most certainly would break legacy code.

In a tremendously popular language like JavaScript, backward compatibility is most certainly going to be an important consideration. Adding new properties to Object.prototype at this point could prove to be disastrous.

I guess an answer to your question is "Because the committee decided so", but I can already hear you ask "why?" before the end of this sentence.

I read about this recently but I can't find the source right now. What it boiled down to was that in many cases you had to use Object.prototype.keys.call(myobject) anyway, because the likelihood of myobject.keys already being used in the object for something else.

I think you will find this archived mail thread interesting, where for example Brendan Eich discuss some aspects of the new methods in ECMAScript 5.

Update:While digging in the mail-archive I found this:

Topic: Should Object.keys be repositioned as Object.prototype.keys

Discussion: Allen argued that this isn't really a meta layer operation as it is intended for use in application layer code as an alternative to for..in for getting a list of enumerable property names. As a application layer method it belongs on Object.prototype rather than on the Object constructor. There was general agreement in principle, but it was pragmatically argued by Doug and Mark that it is too likely that a user defined object would define its own property named "keys" which would shadow Object.prototype.keys making it inaccessible for use on such objects.

Action: Leave it as Object.keys.

Feel free to make your own, but the more properties you add to the Object prototype, the higher chance you'll collide. These collisions will most likely break any third party javascript library, and any code that relies on a for...in loop.

Object.prototype.keys = function () {    return Object.keys(this);};for (var key in {}) {    // now i'm getting 'keys' in here, wtf?}var something = {    keys: 'foo'};something.keys(); // error