为什么在对象本身（例如Function.name）上定义Function属性，而在Function.prototype上定义方法？

Question

From the API properties are defined like Function.name , and methods like Function.prototype.call() . But in the code I still invoke them in the same way, for example:

function Foo() {console.log("inside Foo")}
console.log(Foo.name);  // Foo
Foo.call();             // inside Foo

Ie I simply put a function name(Foo), then a method/property I want to use. Then why in API do I see properties defined on Function , and methods - on Function.prototype ?

Answer 1

Short answer:

Functions (in general) can be shared among instances, so they go in prototype .

Properties are per-instance, so go in the constructor.

Answer 2

Placing methods in the prototype allows you to share them among all instances, instead of duplicating them for each one.

For example, the behavior of Function.prototype.call does not depend on which function is called. It only needs a reference to the function (received via this argument) in order to call it later.

However, intrinsic data like name must be stored in the function object itself. It can't be stored in the prototype because each function instance has its own name . Well, it could be store as an internal [[Name]] property, and accessed via a getter and setter defined in the prototype , but the data would still need to be stored in the function.

Note there are non-method properties defined in the prototype , eg constructor .

Answer 3

There are actually some argument for placing the default values of immutable values (or objects that are not mutated, by contract) in the prototype for common/expected properties.

Re-assignment of the properties will always be in the 'current this' object (well, object on which the assignment occurs). So if properties are assigned later - in the constructor or even after that - they will be 'promoted' to properties of the actual instance and not the prototype ¹ .

However, since the difference (if any) is very modest, and dependent upon situation, it is common practice just to dump all the property assignments in the constructor. Per-object properties would need to be set individually anyway, regardless of the approach used.

Sharing mutable properties in the [prototype] can get questionable as then the property (when mutated) acts akin to a static variable; mutating shared objects should always be done with care.

---

¹ The only observable difference as to 'where' default properties are assigned is if hasOwnProperty is used.

Interesting related-ish read: Should I put default values of attributes on the prototype to save space? (And yes, I know this disagrees with my vary first sentence.)

Answer 4

You have a slight misconception here. You can define properties and functions (methods) on the function itself. You can define properties and functions that you want the object that the function construct on the prototype. It's not the same thing.

For example, the .create() method of the base Object constructor is defined as as Object.create() but the .hasOwnProperty() method of object instances is defined as Object.prototype.hasOwnProperty() .

For example, if you have an object mango created from the constructor Fruit() then:

mango.weight(); // method comes from Fruit.prototype.weight()
Fruit.isFruit(mango); // method comes from Fruit.isFruit()

In particular, the this inside Fruit.isFruit() refers to the function Fruit() while the this inside Fruit.prototype.weight() in the above example refers to the object mango .

If you are used to OO programming from other languages, the difference is between static and non-static class members.

Answer 5

prototype properties (such as the method Foo.prototype.call ) are accessible using instances of the object, while direct properties (such as Foo.name ) are accessible through the object itself (and not its instances) like static properties.

In your example there is a big difference between Foo.name and Foo.prototype.call , in order to use Foo.name you can call it directly, while in order to use Foo.prototype.call - you need to create an instance, and then it'll be available

function Foo(){}
Foo.prototype.call = funciton(){console.log('I was called');}
Foo.name = 'My name is';

console.log(Foo.name); //My name is

var instance = new Foo();
instances.call(); //I was called

Another thing you need to notice is that both name and call has a native definition in the Function object type in JavaScript - therefore when you call Foo.call() - you call the Function.prototype.call method (which is just like calling Foo(); , with one small difference that doesn't affect in this case)