…But usually we don’t want to totally replace a parent method, but rather to build on top of it, tweak or extend its functionality. We do something in our method, but call the parent method before/after it or in the process.

Of course, there’s an explanation. Let’s get into details, so you’d really understand what’s going on.

In JavaScript, there’s a distinction between a “constructor function of an inheriting class” and all others. In an inheriting class, the corresponding constructor function is labelled with a special internal property [[ConstructorKind]]:"derived".

The difference is:

When a normal constructor runs, it creates an empty object as this and continues with it.

But when a derived constructor runs, it doesn’t do it. It expects the parent constructor to do this job.

So if we’re making a constructor of our own, then we must call super, because otherwise the object with this reference to it won’t be created. And we’ll get an error.

For Rabbit to work, we need to call super() before using this, like here:

Let’s get a little deeper under the hood of super. We’ll see some interesting things by the way.

First to say, from all that we’ve learned till now, it’s impossible for super to work.

Yeah, indeed, let’s ask ourselves, how it could technically work? When an object method runs, it gets the current object as this. If we call super.method() then, how to retrieve the method? Naturally, we need to take the method from the prototype of the current object. How, technically, we (or a JavaScript engine) can do it?

Maybe we can get the method from [[Prototype]] of this, as this.__proto__.method? Unfortunately, that doesn’t work.

Let’s try to do it. Without classes, using plain objects for the sake of simplicity.

Here, rabbit.eat() should call animal.eat() method of the parent object:

At the line (*) we take eat from the prototype (animal) and call it in the context of the current object. Please note that .call(this) is important here, because a simple this.__proto__.eat() would execute parent eat in the context of the prototype, not the current object.

And in the code above it actually works as intended: we have the correct alert.

Now let’s add one more object to the chain. We’ll see how things break:

The code doesn’t work any more! We can see the error trying to call longEar.eat().

It may be not that obvious, but if we trace longEar.eat() call, then we can see why. In both lines (*) and (**) the value of this is the current object (longEar). That’s essential: all object methods get the current object as this, not a prototype or something.

So, in both lines (*) and (**) the value of this.__proto__ is exactly the same: rabbit. They both call rabbit.eat without going up the chain in the endless loop.

Here’s the picture of what happens:

Inside longEar.eat(), the line (**) calls rabbit.eat providing it with this=longEar.

To provide the solution, JavaScript adds one more special internal property for functions: [[HomeObject]].

When a function is specified as a class or object method, its [[HomeObject]] property becomes that object.

This actually violates the idea of “unbound” functions, because methods remember their objects. And [[HomeObject]] can’t be changed, so this bound is forever. So that’s a very important change in the language.

But this change is safe. [[HomeObject]] is used only for calling parent methods in super, to resolve the prototype. So it doesn’t break compatibility.

By the way, Function.prototype has “generic” function methods, like call, bind etc. They are ultimately available in both cases, because for the built-in Object constructor, Object.__proto__ === Function.prototype.