What does anObject.prototype.constructor do?

Question

Suppose we have this constructor:

var Foo = function(){
   this.x = \"y\";
}

Foo and Foo.prototype.constructor ev

Answer 1

.prototype.constructor is just a helper property so that the objects created can easily refer the constructor with this.constructor, or as in your case i.constructor.

Setting it arbitrarily to something else doesn't have any effect except on code that expects to get the constructor of an object with obj.constructor:

if( obj.constructor === Foo ) {
 //It's a Foo
}

So it's a good convention just to leave it be.

The es5shim relies on .constructor.prototype to shim Object.getPrototypeOf

Answer 2

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.