The constructor
property of the prototype
property of a function is meant to point back to the function so that you can ask an object what constructed it. It's set up automatically as part of creating the function object (See Section 13.2 of the spec [or here for a more up-to-date version].) As you've seen, you can override the constructor
property on the Foo.prototype
if you like, to change that, but by default that's what it's for. For years the JavaScript specification only said that the constructor
property would be there and have a given default value (function Foo() { }
will mean that, by default, Foo.prototype.constructor
is Foo
.). But starting in ES2015, that changed, and various operations in the specification now actually use the constructor
property, such as here, here, here, and here.
(Note that the following was written before ES2015's class
feature was added. The below is how you'd do this in ES5 and earlier. In ES2015+, if you're doing constructor functions and inheritance hierarchies, there's no good reason to do the below; just use class
. [If you don't use constructor functions to build inheritance hierarchies?— and you don't have to, there are other ways to do them in JavaScript?— you wouldn't do the below or use class
.])
There's a good reason you can override it, which relates to inheritance. Suppose you want to have a Base
constructor that creates base objects, and a Derived
constructor that creates derived objects with the features of Base
plus the additions/modifications of Derived
. The usual (though not to my mind ideal) way you see that done (absent helper scripts) is:
function Base() {
}
Base.prototype.foo = function() {
console.log("I'm Base#foo");
};
function Derived() {
}
Derived.prototype = new Base(); // So we get all the `Base` stuff
Derived.prototype.bar = function() {
console.log("I'm Derived#bar");
};
var d = new Derived();
d.foo(); // "I'm Base#foo"
d.bar(); // "I'm Derived#bar"
The problem is that now, d.constructor === Base
rather than Derived
. So being able to fix that is important:
...
Derived.prototype = new Base(); // So we get all the `Base` stuff
Object.defineProperty(Derived.prototype, "constructor", { // Fix up
value: Derived,
writable: true,
configurable: true
});
...
(Side note: All of this plumbing?— and complexity around supercalls?— is why ES2015+ have class
syntax.)
Note that the above is not meant to be an ideal way to set up inheritance hierarchies. It's what you usually see, but as I said above, not ideal. Just for completeness, in an environment limited to ES5 syntax, this is better:
function Base() {
}
Base.prototype.foo = function() {
? ? console.log("I'm Base#foo");
};
function Derived() {
Base.call(this); // So Base sets up its stuff
}
Derived.prototype = Object.create(Base.prototype); // So we get all the `Base` stuff
Object.defineProperty(Derived.prototype, "constructor", {
value: Derived,
writable: true,
configurable: true
});
Derived.prototype.bar = function() {
? ? console.log("I'm Derived#bar");
};
var d = new Derived();
d.foo(); // "I'm Base#foo"
d.bar(); // "I'm Derived#bar"
...where in a pre-ES5 environment, you use a shim/polyfill for Object.create
. But again, I don't do this directly (and don't recommend it), I use helper scripts so it's declarative and repeatable.