Why Is It Necessary to Set the Prototype Constructor

Why is it necessary to set the prototype constructor?

It's not always necessary, but it does have its uses. Suppose we wanted to make a copy method on the base Person class. Like this:

// define the Person Class  
function Person(name) {
    this.name = name;
}  

Person.prototype.copy = function() {  
    // return new Person(this.name); // just as bad
    return new this.constructor(this.name);
};  

// define the Student class  
function Student(name) {  
    Person.call(this, name);
}  

// inherit Person  
Student.prototype = Object.create(Person.prototype);

Now what happens when we create a new Student and copy it?

var student1 = new Student("trinth");  
console.log(student1.copy() instanceof Student); // => false

The copy is not an instance of Student. This is because (without explicit checks), we'd have no way to return a Student copy from the "base" class. We can only return a Person. However, if we had reset the constructor:

// correct the constructor pointer because it points to Person  
Student.prototype.constructor = Student;

...then everything works as expected:

var student1 = new Student("trinth");  
console.log(student1.copy() instanceof Student); // => true

When is it necessary to set the 'prototype.constructor' property of a class in Javascript?

Each function has a prototype property (even if you did not define it), prototype object has the only property constructor (pointing to a function itself). Hence after you did Student.prototype = new Person(); constructor property of prototype is pointing on Person function, so you need to reset it.

You should not consider prototype.constructor as something magical, it's just a pointer to a function. Even if you skip line Student.prototype.constructor = Student; line new Student(); will work as it should.

constructor property is useful e.g. in following situations (when you need to clone object but do not know exactly what function had created it):

var st = new Student();
...
var st2 = st.constructor();

so it's better to make sure prototype.constructor() is correct.

Why set prototype's constructor to its constructor function?

It restores the .constructor property that was on the original prototype object that you overwrote. People restore it because it's expected to be there.

Some people like to do...

if (my_obj.constructor === Car) { ... }

This isn't required, since instanceof is a better test IMO.

if (my_obj instanceof Car) { ... }

if (my_obj instanceof Vehicle) { ... }

Why assign Something to Something.prototype.constructor?

By default, every prototype has a constructor property that refers to the function that it "belongs" to.

function A() {

}

console.log(A.prototype.constructor === A); // true

Why does prototype's constructor refer back to itself?

If you want to look up the prototype chain described there:

Each object has a private property which holds a link to another object called its prototype. That prototype object has a prototype of its own, and so on until an object is reached with null as its prototype. By definition, null has no prototype, and acts as the final link in this prototype chain.

You should look at the __proto__ properties (which will point to the internal prototype of the object being examined).

Here, you see that the internal prototype of myFunctionObj is Function.prototype, and going up the next level of __proto__ takes you to Object.prototype, which has no __proto__ (the end of the prototype chain).

The prototype property of myFunctionObj refers to the internal prototype of instantiated objects (like const obj = new myFunctionObj();, and then obj.__proto__ === myFunctionObj.prototype), not to the internal prototype of the myFunctionObj itself.

Only functions have a .prototype property, usually, and their .prototype will refer to the internal prototype of instances created with new. Plain objects don't have a .prototype property (because plain objects can't be called to instantiate something), but you can still access the internal prototype of a plain object (or of anything) using Object.getPrototypeOf (or .__proto__):

const obj = {};

console.log(

  obj.__proto__ === Object.prototype,

  Object.getPrototypeOf(obj) === Object.prototype,

);

Why do we set Child constructors to themselves?

JavaScript is a prototype-based language — each object has a prototype object, which acts as a template object that it inherits methods and properties from. An object's prototype object may also have a prototype object, which it inherits methods and properties from, and so on. This is often referred to as a prototype chain, and explains why different objects have properties and methods defined on other objects available to them.
The properties and methods are defined on the Objects' constructor functions, not the object instances themselves.
In classic OOP, classes are defined, then when object instances are created all the properties and methods defined on the class are copied over to the instance. In JavaScript, they are not copied over — instead, a link is made between the object instance and its constructor (a link in the prototype chain), and the properties and methods are found in the constructor by walking up the chain.

If you move ahead with oops in Javascript you will realize that certain attributes are inherited while others are not, this is because inherited ones are the ones defined on the prototype property (you could call it a sub namespace) — that is, the ones that begin with Object.prototype., and not the ones that begin with just Object. The prototype property's value is an object, which is basically a bucket for storing properties and methods that we want to be inherited by objects further down the prototype chain.

So if you want that you are able to access all the data members and functions properly, you should follow explicitly defining the constructor or else you won't be able to access few functions and data members.

---

Related Topics