Is there a difference between these 2 ways of inheritance?

Question

the problem is I don't see a difference, when we want to establish an inheritance, between these 2 methods:

Child.prototype = Object.create( Father.prototype );
Child.prototype.constructor = Child;

and:

Child.prototype.__proto__ = Father.prototype;

The first option allows us to get all the properties and methods that our Father is sharing but overwriting the Child constructor in the process. That's what we need to set the Child constructor back to Child again. The second method does the same but without the overwriting. So, why people/Guides don't use the second option? Am I wrong in anything?

This is a complete example:

function Father( name ) {
  this.name = name;
}

Father.prototype.getName = function() {
  console.log( this.name );
}

function Child( name, lastName ) {
  Father.call( this, name );
  this.lastName = lastName;
}

Child.prototype.__proto__ = Father.prototype;

//Child.prototype = Object.create( Father.prototype );
//Child.prototype.constructor = Child;

var c = new Child( 'Will' , 'Travolta');
c.getName();

Well, for a start it wasn't until ES5 that `__proto__` was even standartised. So anything from before that shouldn't have been recommending it. — VLAZ, May 06 '19 at 21:53
Apart from `__proto__` being deprecated, there's hardly any difference in the outcome. — Bergi, May 06 '19 at 21:55
@VLAZ `__proto__` was not standardised in ES5, `Object.getPrototypeOf` was. ES6 brought `Object.setPrototypeOf` and rules for web-compability (which include `__proto__`). — Bergi, May 06 '19 at 21:56
@Bergi yeah, sorry. I was referring to the web compatibility. I really shouldn't have said "standartised". — VLAZ, May 06 '19 at 21:57
Anyway, yeah - I'm not sure why you say we *need* to override the constructor back to the original, OP - [changing the prototype shouldn't affect that](https://jsbin.com/gozivew/edit?js,console). — VLAZ, May 06 '19 at 21:58
Wouldn't use either. Use a library that does it for you (or crib code from one). Or use classes and babel. Or, given the state of things at this point, use classes without babel. Or better yet, forget about inheritance entirely. — Jared Smith, May 06 '19 at 21:59
@VLAZ, because if in the future you need to know the constructor of that Child you will have the wrong information because of the overwritten. For example: in the [code](https://jsbin.com/bejiyepowu/edit?js,console), when you ask about the Child constructor, the console will say `Father` when in reality we used `new Child()` — Skipydie, May 07 '19 at 01:06

Bergi · Accepted Answer · 2019-05-07T06:21:14.473

I don't see a difference between these 2 methods

There is no difference in the outcome indeed (apart from minor details such as the enumerability of the .constructor property).

So, why people/Guides don't use the second option?

Because __proto__ is deprecated, while Object.create works about anywhere. It was standardised with ES5 and can easily be polyfilled for older environments.

Since ES6, you could also use Object.setPrototypeOf, but since ES6, you'd just write class Child extends Father { … }.

score 0 · Answer 2 · answered May 06 '19 at 22:21

As written in comments, __proto__ is currently deprecated in favour of Object.getPrototypeOf() and Object.setPrototypeOf(). Beside that, there are a lot of open discussions about correctness of completely overwriting a constructor prototype vs. individually adding/removing properties/methods to/from it. Both practices are widely accepted/implemented and it is a fact that destroying prototype.constructor (or all the prototype of an object) does no harm in most cases. I prefer individual manipulation as it should be future proof. Please note that writing Child.prototype = Object.create(Father.prototype) you are destroying the original prototype.

Is there a difference between these 2 ways of inheritance?

2 Answers2