Consider the following code:<\/p>\n
\r\nfunction Foo() {}\r\nvar fooPrototype = Object.getPrototypeOf(Foo);\r\nconsole.log(Foo.prototype === fooPrototype); \/\/ false\r\n<\/pre>\nWhy is it false? Because Foo.prototype<\/code> is in fact not the prototype of Foo, but the prototype of objects created via expression new Foo()<\/code>:<\/p>\n\r\nvar obj = new Foo();\r\nvar objPrototype = Object.getPrototypeOf(obj);\r\nconsole.log(Foo.prototype === objPrototype); \/\/ true\r\n<\/pre>\nAs for the actual prototype of Foo, it is Function.prototype<\/code>:<\/p>\n\r\nconsole.log(fooPrototype === Function.prototype); \/\/ true\r\n<\/pre>\nThis is very<\/i> confusing for someone who is trying to learn about prototypes. Although JavaScript is built on prototypes, it is inexplicably shy about discovering and working with prototypes. To the best of my knowledge, Object.getPrototypeOf()<\/code> was added only in EcmaScript 5.1, 14 years after JavaScript’s inception. For older versions of JavaScript it is recommended to use obj.constructor.prototype<\/code> to retrieve prototype of obj<\/code>. This is rather indirect, and it would fail is someone reassign the constructor<\/code> property. <\/p>\nTo visualize how ridiculous this situation is, let’s mentally transfer it to another language. The concept of prototypes is as central to JavaScript as the concept of base (super) classes to object-oriented languages. A similar situation in Java would mean that:<\/p>\n
\n- There is no keyword
super<\/code>.<\/li>\n- You can refer to the superclass portion of your object as
this.constructor.super<\/code>.<\/li>\n- There is a non-standard property
__super__<\/code> supported only on some JVMs, but not others.<\/li>\n- Method
Object.getSuperOf()<\/code> is finally added in Java 7.<\/li>\n- For any class C, expression
C.super<\/code> yields Class.class<\/code>.<\/li>\nThis would make Java language a little bit of a mess, and we would ask WTF, wouldn’t we?
\n