Type inheritance: Why do you have to create a new object instead of setting the prototype directly?

Question

I try to understand the prototype-based inheritance in JavaScript. To establish a prototype chain with constructor functions, you usually do it this way:

function Person( name, gender ){
    this.name = name;
    this.gender = gender;
}

function Male( name ){
    Person.call(this, name, "male");
}

Male.prototype = Object.create( Person.prototype );

Object.defineProperty( Male.prototype, "constructor", {
    enumerable: false, value: Male, writeable: true
});

var person1 = new Male( "Chris" );

So, for Male.prototype you create a completely new object which has the internal [[prototype]] property set to the parent object. Because it is a new object, you still have to add a non-enumerable constructor property.

Since there is a way to set the [[prototype]] property directly, I wonder why you can't do this:

function Person( name, gender ){
    this.name = name;
    this.gender = gender;
}

function Male( name ){
    Person.call(this, name, "male");
}

Object.setPrototypeOf( Male.prototype, Person.prototype );

var person1 = new Male( "Chris" );

With this solution you just set the [[prototype]] property of Male.prototype to the parent object. (Before ES6 you could have used the __proto__ property to set the prototype.) You don't need to create a new object (because as far as I know the js runtime automatically attaches a new prototype object to every function) and you don't need to create the correct constructor property explicitly, because it is already there.

My question is: why does nobody use this approach to set the prototype chain? Where is the problem?

Answer 1

This is a subtle but VERY important point. If you set the Male prototype to the Person prototype, they will be sharing ONE instance of an object. Any changes to the Person prototype will affect ALL instances of both the Person and Male objects and vice versa. Now, initially, this seems like the desired behavior, but you have to keep the concepts of "types" separate from "instances" here.

By giving Male a new instance of Person as its prototype, you gain the benefits of inheritance, but you de-couple the actual instance of Person that all Person instances are using from the instance that all Male instances will use.

This allows you to make changes to the Male.prototype without affecting any Person instances.

Answer 2

That's a interesting question. I didn't know about the existence of the setPrototypeOf method. Apparently the performance is worst than using Object.create

If you care about performance you should avoid setting the [[Prototype]] of an object. Instead, create a new object with the desired [[Prototype]] using Object.create().

See more in the link from developer.mozilla.org

Answer 3

I had the same doubt a few days ago and I asked about it here: https://softwareengineering.stackexchange.com/questions/343778/when-doing-inheritance-why-not-simply-modify-the-prototype-property-of-the

Apparently, there's no real consensus as to why we shouldn't do Object.setPrototypeOf( Child.prototype, Parent.prototype ), but there are general warnings thrown at us from Mozilla (MDN).

Warning: Changing the [[Prototype]] of an object is, by the nature of how modern JavaScript engines optimize property accesses, a very slow operation, in every browser and JavaScript engine. The effects on performance of altering inheritance are subtle and far-flung, and are not limited to simply the time spent in obj.__proto__ = ... statement, but may extend to any code that has access to any object whose [[Prototype]] has been altered. If you care about performance you should avoid setting the [[Prototype]] of an object. Instead, create a new object with the desired [[Prototype]] using Object.create().

Bottom line is: don't do it!

It breeds uncertainty in the code.