5

While still struggling to read "You don't know JS", I am start to have good idea(love this series). I think I get the hang of prototype but I ran into below code.

   var myObject = {
     a:2
   };

   Object.getOwnPropertyDescriptor(myObject, "a");

And while I fully comprehend the output and its meaning, I was trying to use my understanding (or lack thereof) of prototype and wanted to do below.

   myObject.getOwnPropertyDescriptor

I thought it would traverse up the proto chain up to Object's prototype and get that method but as it turns out, Object's prototype does not have this (assume this is not part of prototype of object as I am looking up the doc, at least I don't see it as part of prototype and it says it's a method). So instead of being Object.prototype.getOwnPropertyDescriptor, I assume this is just Object.getOwnPropertyDescriptor.

Am I understanding this correctly and what is the reason why Object's method is not on all prototype?

user3502374
  • 781
  • 1
  • 4
  • 12
  • We won't be able to tell you why a design decision was made, unless one of us was on the committee which designed the language. We can only speculate, which is not a good fit for Stack Overflow. But, as the existing answers show, we can tell you that you are understanding correctly. – Heretic Monkey Dec 16 '15 at 18:45

2 Answers2

2

this is not part of the prototype of Object... it's a method

You're exactly right. This can be immediately verified in a js console:

> Object.getOwnPropertyDescriptor
getOwnPropertyDescriptor() { [native code] }
> Object.prototype.getOwnPropertyDescriptor
undefined

In a more strictly OOP language, you might call getOwnPropertyDescriptor a static method. More properly, it's not part of the prototype chain.

Chris
  • 6,805
  • 3
  • 35
  • 50
  • Is this just design issue? Why didn't javascript people put everything under prototype when they were designing Object in the first place?? – user3502374 Dec 16 '15 at 18:43
  • "Why didn't javascript people do X?" is a complicated question, mostly to do with the fact the Brendan Eich built javascript in a few days. But, more to the point, you don't want to put everything under prototype because a given method might not be useful or semantically meaningful as a part of every object in the language. – Chris Dec 16 '15 at 18:45
  • Thank you and answer accepted. However, I just have to say, the way things gets looked up proto chain wise, my newly created object will look at Object's prototype first and not Object, so I felt like I would have put everything under prototype. – user3502374 Dec 16 '15 at 18:50
  • I strongly suggest you read a little about OOP. Here's a good place to start on why "static" methods are useful, and why you don't want everything as part of your instance objects: http://stackoverflow.com/questions/2080150/when-should-i-use-static-methods-in-a-class-and-what-are-the-benefits – Chris Dec 16 '15 at 18:53
  • thank you and much appreciated and yes, I don't have formal training in OOP(in classic sense) so this is needed. I will peruse them. thank you so much! – user3502374 Dec 16 '15 at 18:54
1

In fact Object.getOwnPropertyDescriptor(myObject, "a") calls myObject.GetOwnProperty("a") but it's an internal method. source

We can only speculate why it was made this way, but I think it makes sense to define these utility functions as methods of Object object instead of making them inheritable via Object.prototype.

A more clear example would be Object.keys method. If it was Object.prototype.keys it would cause trouble every time we wanted to create var inMyPocket = { keys : true }. So now to reliably list keys of the object we would need to use Object.prototype.keys.call( inMyPocket ), because we couldn't be sure if inMyPocket.keys() refers to the prototype method or was re-defined.

pawel
  • 35,827
  • 7
  • 56
  • 53