Related
In the section about inheritance in the MDN article Introduction to Object Oriented Javascript, I noticed they set the prototype.constructor:
// correct the constructor pointer because it points to Person
Student.prototype.constructor = Student;
Does this serve any important purpose? Is it okay to omit it?
It's not always necessary, but it does have its uses. Suppose we wanted to make a copy method on the base Person class. Like this:
// define the Person Class
function Person(name) {
this.name = name;
}
Person.prototype.copy = function() {
// return new Person(this.name); // just as bad
return new this.constructor(this.name);
};
// define the Student class
function Student(name) {
Person.call(this, name);
}
// inherit Person
Student.prototype = Object.create(Person.prototype);
Now what happens when we create a new Student and copy it?
var student1 = new Student("trinth");
console.log(student1.copy() instanceof Student); // => false
The copy is not an instance of Student. This is because (without explicit checks), we'd have no way to return a Student copy from the "base" class. We can only return a Person. However, if we had reset the constructor:
// correct the constructor pointer because it points to Person
Student.prototype.constructor = Student;
...then everything works as expected:
var student1 = new Student("trinth");
console.log(student1.copy() instanceof Student); // => true
Does this serve any important purpose?
Yes and no.
In ES5 and earlier, JavaScript itself didn't use constructor for anything. It defined that the default object on a function's prototype property would have it and that it would refer back to the function, and that was it. Nothing else in the specification referred to it at all.
That changed in ES2015 (ES6), which started using it in relation to inheritance hierarchies. For instance, Promise#then uses the constructor property of the promise you call it on (via SpeciesConstructor) when building the new promise to return. It's also involved in subtyping arrays (via ArraySpeciesCreate).
Outside of the language itself, sometimes people would use it when trying to build generic "clone" functions or just generally when they wanted to refer to what they believed would be the object's constructor function. My experience is that using it is rare, but sometimes people do use it.
Is it okay to omit it?
It's there by default, you only need to put it back when you replace the object on a function's prototype property:
Student.prototype = Object.create(Person.prototype);
If you don't do this:
Student.prototype.constructor = Student;
...then Student.prototype.constructor inherits from Person.prototype which (presumably) has constructor = Person. So it's misleading. And of course, if you're subclassing something that uses it (like Promise or Array) and not using class¹ (which handles this for you), you'll want to make sure you set it correctly. So basically: It's a good idea.
It's okay if nothing in your code (or library code you use) uses it. I've always ensured it was correctly wired up.
Of course, with ES2015 (aka ES6)'s class keyword, most of the time we would have used it, we don't have to anymore, because it's handled for us when we do
class Student extends Person {
}
¹ "...if you're subclassing something that uses it (like Promise or Array) and not using class..." — It's possible to do that, but it's a real pain (and a bit silly). You have to use Reflect.construct.
TLDR; Not super necessary, but will probably help in the long run, and it is more accurate to do so.
NOTE: Much edited as my previous answer was confusingly written and had some errors that I missed in my rush to answer. Thanks to those who pointed out some egregious errors.
Basically, it's to wire subclassing up correctly in Javascript. When we subclass, we have to do some funky things to make sure that the prototypal delegation works correctly, including overwriting a prototype object. Overwriting a prototype object includes the constructor, so we then need to fix the reference.
Let's quickly go through how 'classes' in ES5 work.
Let's say you have a constructor function and its prototype:
//Constructor Function
var Person = function(name, age) {
this.name = name;
this.age = age;
}
//Prototype Object - shared between all instances of Person
Person.prototype = {
species: 'human',
}
When you call the constructor to instantiate, say Adam:
// instantiate using the 'new' keyword
var adam = new Person('Adam', 19);
The new keyword invoked with 'Person' basically will run the Person constructor with a few additional lines of code:
function Person (name, age) {
// This additional line is automatically added by the keyword 'new'
// it sets up the relationship between the instance and the prototype object
// So that the instance will delegate to the Prototype object
this = Object.create(Person.prototype);
this.name = name;
this.age = age;
return this;
}
/* So 'adam' will be an object that looks like this:
* {
* name: 'Adam',
* age: 19
* }
*/
If we console.log(adam.species), the lookup will fail at the adam instance, and look up the prototypal chain to its .prototype, which is Person.prototype - and Person.prototype has a .species property, so the lookup will succeed at Person.prototype. It will then log 'human'.
Here, the Person.prototype.constructor will correctly point to Person.
So now the interesting part, the so-called 'subclassing'. If we want to create a Student class, that is a subclass of the Person class with some additional changes, we'll need to make sure that the Student.prototype.constructor points to Student for accuracy.
It doesn't do this by itself. When you subclass, the code looks like this:
var Student = function(name, age, school) {
// Calls the 'super' class, as every student is an instance of a Person
Person.call(this, name, age);
// This is what makes the Student instances different
this.school = school
}
var eve = new Student('Eve', 20, 'UCSF');
console.log(Student.prototype); // this will be an empty object: {}
Calling new Student() here would return an object with all of the properties we want. Here, if we check eve instanceof Person, it would return false. If we try to access eve.species, it would return undefined.
In other words, we need to wire up the delegation so that eve instanceof Person returns true and so that instances of Student delegate correctly to Student.prototype, and then Person.prototype.
BUT since we're calling it with the new keyword, remember what that invocation adds? It would call Object.create(Student.prototype), which is how we set up that delegational relationship between Student and Student.prototype. Note that right now, Student.prototype is empty. So looking up .species an instance of Student would fail as it delegates to only Student.prototype, and the .species property doesn't exist on Student.prototype.
When we do assign Student.prototype to Object.create(Person.prototype), Student.prototype itself then delegates to Person.prototype, and looking up eve.species will return human as we expect. Presumably we would want it to inherit from Student.prototype AND Person.prototype. So we need to fix all of that.
/* This sets up the prototypal delegation correctly
*so that if a lookup fails on Student.prototype, it would delegate to Person's .prototype
*This also allows us to add more things to Student.prototype
*that Person.prototype may not have
*So now a failed lookup on an instance of Student
*will first look at Student.prototype,
*and failing that, go to Person.prototype (and failing /that/, where do we think it'll go?)
*/
Student.prototype = Object.create(Person.prototype);
Now the delegation works, but we're overwriting Student.prototype with an of Person.prototype. So if we call Student.prototype.constructor, it would point to Person instead of Student. This is why we need to fix it.
// Now we fix what the .constructor property is pointing to
Student.prototype.constructor = Student
// If we check instanceof here
console.log(eve instanceof Person) // true
In ES5, our constructor property is a reference that refers to a function that we've written with the intent to be a 'constructor'. Aside from what the new keyword gives us, the constructor is otherwise a 'plain' function.
In ES6, the constructor is now built into the way we write classes - as in, it's provided as a method when we declare a class. This is simply syntactic sugar but it does accord us some conveniences like access to a super when we are extending an existing class. So we would write the above code like this:
class Person {
// constructor function here
constructor(name, age) {
this.name = name;
this.age = age;
}
// static getter instead of a static property
static get species() {
return 'human';
}
}
class Student extends Person {
constructor(name, age, school) {
// calling the superclass constructor
super(name, age);
this.school = school;
}
}
I'd disagree. It isn't necessary to set the prototype. Take that exact same code but remove the prototype.constructor line. Does anything change? No. Now, make the following changes:
Person = function () {
this.favoriteColor = 'black';
}
Student = function () {
Person.call(this);
this.favoriteColor = 'blue';
}
and at the end of the test code...
alert(student1.favoriteColor);
The color will be blue.
A change to the prototype.constructor, in my experience, doesn't do much unless you're doing very specific, very complicated things that probably aren't good practice anyway :)
Edit:
After poking around the web for a bit and doing some experimentation, it looks like people set the constructor so that it 'looks' like the thing that is being constructed with 'new'. I guess I would argue that the problem with this is that javascript is a prototype language - there is no such thing as inheritence. But most programmers come from a background of programming that pushes inheritence as 'the way'. So we come up with all sorts of things to try and make this prototypical language a 'classic' language.. such as extending 'classes'. Really, in the example they gave, a new student is a person - it isn't 'extending' from another student.. the student is all about the person, and whatever the person is the student is as well. Extend the student, and whatever you've extended is a student at heart, but is customized to fit your needs.
Crockford is a bit crazy and overzealous, but do some serious reading on some of the stuff that he's written.. it'll make you look at this stuff very differently.
This has the huge pitfall that if you wrote
Student.prototype.constructor = Student;
but then if there was a Teacher whose prototype was also Person and you wrote
Teacher.prototype.constructor = Teacher;
then the Student constructor is now Teacher!
Edit:
You can avoid this by ensuring that you had set the Student and Teacher prototypes using new instances of the Person class created using Object.create, as in the Mozilla example.
Student.prototype = Object.create(Person.prototype);
Teacher.prototype = Object.create(Person.prototype);
So far confusion is still there.
Following the original example, as you have an existing object student1 as:
var student1 = new Student("Janet", "Applied Physics");
Suppose you don't want to know how student1 is created, you just want another object like it, you can use the constructor property of student1 like:
var student2 = new student1.constructor("Mark", "Object-Oriented JavaScript");
Here it will fail to get the properties from Student if the constructor property is not set. Rather it will create a Person object.
Got a nice code example of why it is really necessary to set the prototype constructor..
function CarFactory(name){
this.name=name;
}
CarFactory.prototype.CreateNewCar = function(){
return new this.constructor("New Car "+ this.name);
}
CarFactory.prototype.toString=function(){
return 'Car Factory ' + this.name;
}
AudiFactory.prototype = new CarFactory(); // Here's where the inheritance occurs
AudiFactory.prototype.constructor=AudiFactory; // Otherwise instances of Audi would have a constructor of Car
function AudiFactory(name){
this.name=name;
}
AudiFactory.prototype.toString=function(){
return 'Audi Factory ' + this.name;
}
var myAudiFactory = new AudiFactory('');
alert('Hay your new ' + myAudiFactory + ' is ready.. Start Producing new audi cars !!! ');
var newCar = myAudiFactory.CreateNewCar(); // calls a method inherited from CarFactory
alert(newCar);
/*
Without resetting prototype constructor back to instance, new cars will not come from New Audi factory, Instead it will come from car factory ( base class ).. Dont we want our new car from Audi factory ????
*/
No need for sugared function 'classes' or using 'New' these days. Use object literals.
The Object prototype is already a 'class'. When you define an object literal, it is already an instance of the prototype Object. These can also act as another object's prototype, etc.
const Person = {
name: '[Person.name]',
greeting: function() {
console.log( `My name is ${ this.name || '[Name not assigned]' }` );
}
};
// Person.greeting = function() {...} // or define outside the obj if you must
// Object.create version
const john = Object.create( Person );
john.name = 'John';
console.log( john.name ); // John
john.greeting(); // My name is John
// Define new greeting method
john.greeting = function() {
console.log( `Hi, my name is ${ this.name }` )
};
john.greeting(); // Hi, my name is John
// Object.assign version
const jane = Object.assign( Person, { name: 'Jane' } );
console.log( jane.name ); // Jane
// Original greeting
jane.greeting(); // My name is Jane
// Original Person obj is unaffected
console.log( Person.name ); // [Person.name]
console.log( Person.greeting() ); // My name is [Person.name]
This is worth a read:
Class-based object-oriented languages, such as Java and C++, are
founded on the concept of two distinct entities: classes and
instances.
...
A prototype-based language, such as JavaScript, does not make this
distinction: it simply has objects. A prototype-based language has the
notion of a prototypical object, an object used as a template from
which to get the initial properties for a new object. Any object can
specify its own properties, either when you create it or at run time.
In addition, any object can be associated as the prototype for another
object, allowing the second object to share the first object's
properties
It is necessary when you need an alternative to toString without monkeypatching:
//Local
foo = [];
foo.toUpperCase = String(foo).toUpperCase;
foo.push("a");
foo.toUpperCase();
//Global
foo = [];
window.toUpperCase = function (obj) {return String(obj).toUpperCase();}
foo.push("a");
toUpperCase(foo);
//Prototype
foo = [];
Array.prototype.toUpperCase = String.prototype.toUpperCase;
foo.push("a");
foo.toUpperCase();
//toString alternative via Prototype constructor
foo = [];
Array.prototype.constructor = String.prototype.toUpperCase;
foo.push("a,b");
foo.constructor();
//toString override
var foo = [];
foo.push("a");
var bar = String(foo);
foo.toString = function() { return bar.toUpperCase(); }
foo.toString();
//Object prototype as a function
Math.prototype = function(char){return Math.prototype[char]};
Math.prototype.constructor = function()
{
var i = 0, unicode = {}, zero_padding = "0000", max = 9999;
while (i < max)
{
Math.prototype[String.fromCharCode(parseInt(i, 16))] = ("u" + zero_padding + i).substr(-4);
i = i + 1;
}
}
Math.prototype.constructor();
console.log(Math.prototype("a") );
console.log(Math.prototype["a"] );
console.log(Math.prototype("a") === Math.prototype["a"]);
EDIT, I was actually wrong. Commenting the line out doesn't change it's behavior at all. (I tested it)
Yes, it is necessary. When you do
Student.prototype = new Person();
Student.prototype.constructor becomes Person. Therefore, calling Student() would return an object created by Person. If you then do
Student.prototype.constructor = Student;
Student.prototype.constructor is reset back to Student. Now when you call Student() it executes Student, which calls the parent constructor Parent(), it returns the correctly inherited object. If you didn't reset Student.prototype.constructor before calling it you would get an object that would not have any of the properties set in Student().
Given simple constructor function:
function Person(){
this.name = 'test';
}
console.log(Person.prototype.constructor) // function Person(){...}
Person.prototype = { //constructor in this case is Object
sayName: function(){
return this.name;
}
}
var person = new Person();
console.log(person instanceof Person); //true
console.log(person.sayName()); //test
console.log(Person.prototype.constructor) // function Object(){...}
By default (from the specification https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/constructor), all prototypes automatically get a property called constructor that points back to the function on which it is a property.
Depending on the constructor, other properties and methods might be added to the prototype which is not a very common practice but still it is allowed for extensions.
So simply answering: we need make sure that the value in prototype.constructor is correctly set as it is supposed by the specification to be.
Do we have to always set correctly this value? It helps with debugging and makes internal structure consistent against specification. We should definitely when our API is being used by the thirdparties, but not really when the code is finally executed in the runtime.
Here's one example from MDN which I found very helpful to understand its uses.
In JavaScript, we have async functions which returns AsyncFunction object. AsyncFunction is not a global object but one may retrieve it by using constructor property and utilize it.
function resolveAfter2Seconds(x) {
return new Promise(resolve => {
setTimeout(() => {
resolve(x);
}, 2000);
});
}
// AsyncFunction constructor
var AsyncFunction = Object.getPrototypeOf(async function(){}).constructor
var a = new AsyncFunction('a',
'b',
'return await resolveAfter2Seconds(a) + await resolveAfter2Seconds(b);');
a(10, 20).then(v => {
console.log(v); // prints 30 after 4 seconds
});
It is necessary. Any class in class inheritance must has its own constructor, so as in prototype inheritance.It is also convenient for object construction. But the question is unnecessary and what is necessary is understanding in JavaScript world effect of calling function as constructor and rule of resolving object property.
Effect of executing function as constructor with expression new <function name>( [ parameters] )
a object whose type name is the function name is created
inner properties in the function attaches to the created object
property prototype of the function attaches automatically to the created object as prototype
Rule of resolving property of object
The property will not only be sought on the object but on the prototype of the object, the prototype of the prototype, and so on until either a property with a matching name is found or the end of the prototype chain is reached.
Basing on these underlying mechanisms, statement <constructor name>.prototype.constructor = <constructor name> equals in term of effect to attach constructor in constructor body with expression this.constructor = <constructor name>. The constructor will be resolved on the object if second utterance while on object's prototype if first utterance.
It is not necessary. It is just one of the many things traditional, OOP champions do to try to turn JavaScript's prototypical inheritance into classical inheritance. The only thing that the following
Student.prototype.constructor = Student;
does, is that you now have a reference of the current "constructor".
In Wayne's answer, that has been marked as correct, you could the exact same thing that the following code does
Person.prototype.copy = function() {
// return new Person(this.name); // just as bad
return new this.constructor(this.name);
};
with the code below (just replace this.constructor with Person)
Person.prototype.copy = function() {
// return new Person(this.name); // just as bad
return new Person(this.name);
};
Thank God that with ES6 classical inheritance purists can use language's native operators like class, extends and super and we don't have to see like prototype.constructor corrections and parent refereces.
In the section about inheritance in the MDN article Introduction to Object Oriented Javascript, I noticed they set the prototype.constructor:
// correct the constructor pointer because it points to Person
Student.prototype.constructor = Student;
Does this serve any important purpose? Is it okay to omit it?
It's not always necessary, but it does have its uses. Suppose we wanted to make a copy method on the base Person class. Like this:
// define the Person Class
function Person(name) {
this.name = name;
}
Person.prototype.copy = function() {
// return new Person(this.name); // just as bad
return new this.constructor(this.name);
};
// define the Student class
function Student(name) {
Person.call(this, name);
}
// inherit Person
Student.prototype = Object.create(Person.prototype);
Now what happens when we create a new Student and copy it?
var student1 = new Student("trinth");
console.log(student1.copy() instanceof Student); // => false
The copy is not an instance of Student. This is because (without explicit checks), we'd have no way to return a Student copy from the "base" class. We can only return a Person. However, if we had reset the constructor:
// correct the constructor pointer because it points to Person
Student.prototype.constructor = Student;
...then everything works as expected:
var student1 = new Student("trinth");
console.log(student1.copy() instanceof Student); // => true
Does this serve any important purpose?
Yes and no.
In ES5 and earlier, JavaScript itself didn't use constructor for anything. It defined that the default object on a function's prototype property would have it and that it would refer back to the function, and that was it. Nothing else in the specification referred to it at all.
That changed in ES2015 (ES6), which started using it in relation to inheritance hierarchies. For instance, Promise#then uses the constructor property of the promise you call it on (via SpeciesConstructor) when building the new promise to return. It's also involved in subtyping arrays (via ArraySpeciesCreate).
Outside of the language itself, sometimes people would use it when trying to build generic "clone" functions or just generally when they wanted to refer to what they believed would be the object's constructor function. My experience is that using it is rare, but sometimes people do use it.
Is it okay to omit it?
It's there by default, you only need to put it back when you replace the object on a function's prototype property:
Student.prototype = Object.create(Person.prototype);
If you don't do this:
Student.prototype.constructor = Student;
...then Student.prototype.constructor inherits from Person.prototype which (presumably) has constructor = Person. So it's misleading. And of course, if you're subclassing something that uses it (like Promise or Array) and not using class¹ (which handles this for you), you'll want to make sure you set it correctly. So basically: It's a good idea.
It's okay if nothing in your code (or library code you use) uses it. I've always ensured it was correctly wired up.
Of course, with ES2015 (aka ES6)'s class keyword, most of the time we would have used it, we don't have to anymore, because it's handled for us when we do
class Student extends Person {
}
¹ "...if you're subclassing something that uses it (like Promise or Array) and not using class..." — It's possible to do that, but it's a real pain (and a bit silly). You have to use Reflect.construct.
TLDR; Not super necessary, but will probably help in the long run, and it is more accurate to do so.
NOTE: Much edited as my previous answer was confusingly written and had some errors that I missed in my rush to answer. Thanks to those who pointed out some egregious errors.
Basically, it's to wire subclassing up correctly in Javascript. When we subclass, we have to do some funky things to make sure that the prototypal delegation works correctly, including overwriting a prototype object. Overwriting a prototype object includes the constructor, so we then need to fix the reference.
Let's quickly go through how 'classes' in ES5 work.
Let's say you have a constructor function and its prototype:
//Constructor Function
var Person = function(name, age) {
this.name = name;
this.age = age;
}
//Prototype Object - shared between all instances of Person
Person.prototype = {
species: 'human',
}
When you call the constructor to instantiate, say Adam:
// instantiate using the 'new' keyword
var adam = new Person('Adam', 19);
The new keyword invoked with 'Person' basically will run the Person constructor with a few additional lines of code:
function Person (name, age) {
// This additional line is automatically added by the keyword 'new'
// it sets up the relationship between the instance and the prototype object
// So that the instance will delegate to the Prototype object
this = Object.create(Person.prototype);
this.name = name;
this.age = age;
return this;
}
/* So 'adam' will be an object that looks like this:
* {
* name: 'Adam',
* age: 19
* }
*/
If we console.log(adam.species), the lookup will fail at the adam instance, and look up the prototypal chain to its .prototype, which is Person.prototype - and Person.prototype has a .species property, so the lookup will succeed at Person.prototype. It will then log 'human'.
Here, the Person.prototype.constructor will correctly point to Person.
So now the interesting part, the so-called 'subclassing'. If we want to create a Student class, that is a subclass of the Person class with some additional changes, we'll need to make sure that the Student.prototype.constructor points to Student for accuracy.
It doesn't do this by itself. When you subclass, the code looks like this:
var Student = function(name, age, school) {
// Calls the 'super' class, as every student is an instance of a Person
Person.call(this, name, age);
// This is what makes the Student instances different
this.school = school
}
var eve = new Student('Eve', 20, 'UCSF');
console.log(Student.prototype); // this will be an empty object: {}
Calling new Student() here would return an object with all of the properties we want. Here, if we check eve instanceof Person, it would return false. If we try to access eve.species, it would return undefined.
In other words, we need to wire up the delegation so that eve instanceof Person returns true and so that instances of Student delegate correctly to Student.prototype, and then Person.prototype.
BUT since we're calling it with the new keyword, remember what that invocation adds? It would call Object.create(Student.prototype), which is how we set up that delegational relationship between Student and Student.prototype. Note that right now, Student.prototype is empty. So looking up .species an instance of Student would fail as it delegates to only Student.prototype, and the .species property doesn't exist on Student.prototype.
When we do assign Student.prototype to Object.create(Person.prototype), Student.prototype itself then delegates to Person.prototype, and looking up eve.species will return human as we expect. Presumably we would want it to inherit from Student.prototype AND Person.prototype. So we need to fix all of that.
/* This sets up the prototypal delegation correctly
*so that if a lookup fails on Student.prototype, it would delegate to Person's .prototype
*This also allows us to add more things to Student.prototype
*that Person.prototype may not have
*So now a failed lookup on an instance of Student
*will first look at Student.prototype,
*and failing that, go to Person.prototype (and failing /that/, where do we think it'll go?)
*/
Student.prototype = Object.create(Person.prototype);
Now the delegation works, but we're overwriting Student.prototype with an of Person.prototype. So if we call Student.prototype.constructor, it would point to Person instead of Student. This is why we need to fix it.
// Now we fix what the .constructor property is pointing to
Student.prototype.constructor = Student
// If we check instanceof here
console.log(eve instanceof Person) // true
In ES5, our constructor property is a reference that refers to a function that we've written with the intent to be a 'constructor'. Aside from what the new keyword gives us, the constructor is otherwise a 'plain' function.
In ES6, the constructor is now built into the way we write classes - as in, it's provided as a method when we declare a class. This is simply syntactic sugar but it does accord us some conveniences like access to a super when we are extending an existing class. So we would write the above code like this:
class Person {
// constructor function here
constructor(name, age) {
this.name = name;
this.age = age;
}
// static getter instead of a static property
static get species() {
return 'human';
}
}
class Student extends Person {
constructor(name, age, school) {
// calling the superclass constructor
super(name, age);
this.school = school;
}
}
I'd disagree. It isn't necessary to set the prototype. Take that exact same code but remove the prototype.constructor line. Does anything change? No. Now, make the following changes:
Person = function () {
this.favoriteColor = 'black';
}
Student = function () {
Person.call(this);
this.favoriteColor = 'blue';
}
and at the end of the test code...
alert(student1.favoriteColor);
The color will be blue.
A change to the prototype.constructor, in my experience, doesn't do much unless you're doing very specific, very complicated things that probably aren't good practice anyway :)
Edit:
After poking around the web for a bit and doing some experimentation, it looks like people set the constructor so that it 'looks' like the thing that is being constructed with 'new'. I guess I would argue that the problem with this is that javascript is a prototype language - there is no such thing as inheritence. But most programmers come from a background of programming that pushes inheritence as 'the way'. So we come up with all sorts of things to try and make this prototypical language a 'classic' language.. such as extending 'classes'. Really, in the example they gave, a new student is a person - it isn't 'extending' from another student.. the student is all about the person, and whatever the person is the student is as well. Extend the student, and whatever you've extended is a student at heart, but is customized to fit your needs.
Crockford is a bit crazy and overzealous, but do some serious reading on some of the stuff that he's written.. it'll make you look at this stuff very differently.
This has the huge pitfall that if you wrote
Student.prototype.constructor = Student;
but then if there was a Teacher whose prototype was also Person and you wrote
Teacher.prototype.constructor = Teacher;
then the Student constructor is now Teacher!
Edit:
You can avoid this by ensuring that you had set the Student and Teacher prototypes using new instances of the Person class created using Object.create, as in the Mozilla example.
Student.prototype = Object.create(Person.prototype);
Teacher.prototype = Object.create(Person.prototype);
So far confusion is still there.
Following the original example, as you have an existing object student1 as:
var student1 = new Student("Janet", "Applied Physics");
Suppose you don't want to know how student1 is created, you just want another object like it, you can use the constructor property of student1 like:
var student2 = new student1.constructor("Mark", "Object-Oriented JavaScript");
Here it will fail to get the properties from Student if the constructor property is not set. Rather it will create a Person object.
Got a nice code example of why it is really necessary to set the prototype constructor..
function CarFactory(name){
this.name=name;
}
CarFactory.prototype.CreateNewCar = function(){
return new this.constructor("New Car "+ this.name);
}
CarFactory.prototype.toString=function(){
return 'Car Factory ' + this.name;
}
AudiFactory.prototype = new CarFactory(); // Here's where the inheritance occurs
AudiFactory.prototype.constructor=AudiFactory; // Otherwise instances of Audi would have a constructor of Car
function AudiFactory(name){
this.name=name;
}
AudiFactory.prototype.toString=function(){
return 'Audi Factory ' + this.name;
}
var myAudiFactory = new AudiFactory('');
alert('Hay your new ' + myAudiFactory + ' is ready.. Start Producing new audi cars !!! ');
var newCar = myAudiFactory.CreateNewCar(); // calls a method inherited from CarFactory
alert(newCar);
/*
Without resetting prototype constructor back to instance, new cars will not come from New Audi factory, Instead it will come from car factory ( base class ).. Dont we want our new car from Audi factory ????
*/
No need for sugared function 'classes' or using 'New' these days. Use object literals.
The Object prototype is already a 'class'. When you define an object literal, it is already an instance of the prototype Object. These can also act as another object's prototype, etc.
const Person = {
name: '[Person.name]',
greeting: function() {
console.log( `My name is ${ this.name || '[Name not assigned]' }` );
}
};
// Person.greeting = function() {...} // or define outside the obj if you must
// Object.create version
const john = Object.create( Person );
john.name = 'John';
console.log( john.name ); // John
john.greeting(); // My name is John
// Define new greeting method
john.greeting = function() {
console.log( `Hi, my name is ${ this.name }` )
};
john.greeting(); // Hi, my name is John
// Object.assign version
const jane = Object.assign( Person, { name: 'Jane' } );
console.log( jane.name ); // Jane
// Original greeting
jane.greeting(); // My name is Jane
// Original Person obj is unaffected
console.log( Person.name ); // [Person.name]
console.log( Person.greeting() ); // My name is [Person.name]
This is worth a read:
Class-based object-oriented languages, such as Java and C++, are
founded on the concept of two distinct entities: classes and
instances.
...
A prototype-based language, such as JavaScript, does not make this
distinction: it simply has objects. A prototype-based language has the
notion of a prototypical object, an object used as a template from
which to get the initial properties for a new object. Any object can
specify its own properties, either when you create it or at run time.
In addition, any object can be associated as the prototype for another
object, allowing the second object to share the first object's
properties
It is necessary when you need an alternative to toString without monkeypatching:
//Local
foo = [];
foo.toUpperCase = String(foo).toUpperCase;
foo.push("a");
foo.toUpperCase();
//Global
foo = [];
window.toUpperCase = function (obj) {return String(obj).toUpperCase();}
foo.push("a");
toUpperCase(foo);
//Prototype
foo = [];
Array.prototype.toUpperCase = String.prototype.toUpperCase;
foo.push("a");
foo.toUpperCase();
//toString alternative via Prototype constructor
foo = [];
Array.prototype.constructor = String.prototype.toUpperCase;
foo.push("a,b");
foo.constructor();
//toString override
var foo = [];
foo.push("a");
var bar = String(foo);
foo.toString = function() { return bar.toUpperCase(); }
foo.toString();
//Object prototype as a function
Math.prototype = function(char){return Math.prototype[char]};
Math.prototype.constructor = function()
{
var i = 0, unicode = {}, zero_padding = "0000", max = 9999;
while (i < max)
{
Math.prototype[String.fromCharCode(parseInt(i, 16))] = ("u" + zero_padding + i).substr(-4);
i = i + 1;
}
}
Math.prototype.constructor();
console.log(Math.prototype("a") );
console.log(Math.prototype["a"] );
console.log(Math.prototype("a") === Math.prototype["a"]);
EDIT, I was actually wrong. Commenting the line out doesn't change it's behavior at all. (I tested it)
Yes, it is necessary. When you do
Student.prototype = new Person();
Student.prototype.constructor becomes Person. Therefore, calling Student() would return an object created by Person. If you then do
Student.prototype.constructor = Student;
Student.prototype.constructor is reset back to Student. Now when you call Student() it executes Student, which calls the parent constructor Parent(), it returns the correctly inherited object. If you didn't reset Student.prototype.constructor before calling it you would get an object that would not have any of the properties set in Student().
Given simple constructor function:
function Person(){
this.name = 'test';
}
console.log(Person.prototype.constructor) // function Person(){...}
Person.prototype = { //constructor in this case is Object
sayName: function(){
return this.name;
}
}
var person = new Person();
console.log(person instanceof Person); //true
console.log(person.sayName()); //test
console.log(Person.prototype.constructor) // function Object(){...}
By default (from the specification https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/constructor), all prototypes automatically get a property called constructor that points back to the function on which it is a property.
Depending on the constructor, other properties and methods might be added to the prototype which is not a very common practice but still it is allowed for extensions.
So simply answering: we need make sure that the value in prototype.constructor is correctly set as it is supposed by the specification to be.
Do we have to always set correctly this value? It helps with debugging and makes internal structure consistent against specification. We should definitely when our API is being used by the thirdparties, but not really when the code is finally executed in the runtime.
Here's one example from MDN which I found very helpful to understand its uses.
In JavaScript, we have async functions which returns AsyncFunction object. AsyncFunction is not a global object but one may retrieve it by using constructor property and utilize it.
function resolveAfter2Seconds(x) {
return new Promise(resolve => {
setTimeout(() => {
resolve(x);
}, 2000);
});
}
// AsyncFunction constructor
var AsyncFunction = Object.getPrototypeOf(async function(){}).constructor
var a = new AsyncFunction('a',
'b',
'return await resolveAfter2Seconds(a) + await resolveAfter2Seconds(b);');
a(10, 20).then(v => {
console.log(v); // prints 30 after 4 seconds
});
It is necessary. Any class in class inheritance must has its own constructor, so as in prototype inheritance.It is also convenient for object construction. But the question is unnecessary and what is necessary is understanding in JavaScript world effect of calling function as constructor and rule of resolving object property.
Effect of executing function as constructor with expression new <function name>( [ parameters] )
a object whose type name is the function name is created
inner properties in the function attaches to the created object
property prototype of the function attaches automatically to the created object as prototype
Rule of resolving property of object
The property will not only be sought on the object but on the prototype of the object, the prototype of the prototype, and so on until either a property with a matching name is found or the end of the prototype chain is reached.
Basing on these underlying mechanisms, statement <constructor name>.prototype.constructor = <constructor name> equals in term of effect to attach constructor in constructor body with expression this.constructor = <constructor name>. The constructor will be resolved on the object if second utterance while on object's prototype if first utterance.
It is not necessary. It is just one of the many things traditional, OOP champions do to try to turn JavaScript's prototypical inheritance into classical inheritance. The only thing that the following
Student.prototype.constructor = Student;
does, is that you now have a reference of the current "constructor".
In Wayne's answer, that has been marked as correct, you could the exact same thing that the following code does
Person.prototype.copy = function() {
// return new Person(this.name); // just as bad
return new this.constructor(this.name);
};
with the code below (just replace this.constructor with Person)
Person.prototype.copy = function() {
// return new Person(this.name); // just as bad
return new Person(this.name);
};
Thank God that with ES6 classical inheritance purists can use language's native operators like class, extends and super and we don't have to see like prototype.constructor corrections and parent refereces.
I've been reading MDN guide on Object Oriented programming with Javascript where in an example to show Inheritance, the following is mentioned:
// Create a Student.prototype object that inherits from Person.prototype.
// Note: A common error here is to use "new Person()" to create the
// Student.prototype. That's incorrect for several reasons, not least
// that we don't have anything to give Person for the "firstName"
// argument. The correct place to call Person is above, where we call
// it from Student.
Student.prototype = Object.create(Person.prototype); // See note below
I've looked into other answers as well, but they don't specifically tell what problems one will face on using Student.prototype = new Person()
One problem mentioned above concerns with passing firstName, but that's just one scenario.
Before anyone marks this as duplicate. The question here Using "Object.create" instead of "new" deals with generally using Object.create instead of constructors and not with what I'm asking.
The question here What is the reason to use the 'new' keyword at Derived.prototype = new Base deals with difference between foo() and new foo()
One answer for this question JavaScript inheritance: Object.create vs new gives one more reason:
When SomeBaseClass has a function body, this would get executed with
the new keyword. This usually is not intended - you only want to set
up the prototype chain. In some cases it even could cause serious
issues because you actually instantiate an object, whose
private-scoped variables are shared by all MyClass instances as they
inherit the same privileged methods. Other side effects are
imaginable.
So, you should generally prefer Object.create. Yet, it is not
supported in some legacy browsers; which is the reason you see the
new-approach much too frequent as it often does no (obvious) harm.
Also have a look at this answer.
Reading the above it seems it depends more on the given scenario being tackled. Is there a stringent reason for MDN saying using new SuperClass() is incorrect?
TL;DR You could use new Person to build your Student.prototype, but doing so complicates all of your constructor functions, limits their ability to detect construction errors, and requires that all constructors everywhere handle that form of use. Since it's more complicated, error-prone, and limiting, most people have gone the other way: Object.create.
The main pragmatic issue is: What if the super constructor requires arguments? Say Person requires a name:
function Person(name) {
this.name = name;
}
How am I to use new Person to create my prototype? I have no name to provide it.
Now, there are two ways to solve this:
Require that all constructors that need arguments detect that they have been called without arguments, assume they're being called to build a prototype, and handle that case correctly.
Use Object.create instead.
Here's the first way:
// NOT WHAT MOST PEOPLE DO
function Person(name) {
if (arguments.length === 0) {
return;
}
this.name = name;
}
function Student(name) {
Person.call(this, name);
}
Student.prototype = new Person;
Student.prototype.constructor = Student;
Note how Person has to detect that it's being called with no arguments, hope that that's because it's being used to create a prototype rather than for some other reason, and avoid trying to use the missing arguments.
That's error-prone and awkward, and it means that Person can't (for instance) raise an error if it doesn't receive name for the final instance construction call. It just doesn't know why it's being called, so it can't tell whether not having name is correct or not.
So most people go the other way:
// What most people do
function Person(name) {
this.name = name;
}
function Student(name) {
Person.call(this, name);
}
Student.prototype = Object.create(Person.prototype);
Student.prototype.constructor = Student;
Person doesn't have to have any special-case code in it, and is free to raise an error if it doesn't get name and needs it.
That's sufficienly ingrained now, as well, that it's baked into ES2015 (aka ES6)'s class keyword. This ES2015 code:
class Student extends Person {
constructor(name) {
super(name);
}
}
Translates fairly closely to the Object.create ES5 code above. (Not exactly, but fairly closely.)
Having a Java-background, when I switched to Javascript, I (lazily) tried to stick with what I knew regarding oop, i.e. a classical inheritance. I'm working on a web-app (that I made), and used this kind of inheritance. However, I'm considering to change my code and rewrite the OOP parts to do prototypal inheritance (two reasons: I read a lot that it's better, and secondly, I need to try the other way in order to have a better understanding of it).
My app creates data visualisations (with D3js, but it's not the topic), and organised my code this way:
function SVGBuilder( dataset ) {
this.data = dataset;
this.xCoord;
this.startDisplaying = function() {
// stuff
this.displayElement();
}
}
The displayElement() method is defined in "classes" inheriting from SVGBuilder (which is more or less an abstract class). I then have:
function SpiralBuilder( dataset ) {
SVGBuilder.call( this, dataset );
this.displayElement = function() {
// stuff
};
}
SpiralBuilder.inheritsFrom( SVGBuilder );
I have several other "builders" based on the same structure.
The script calling the builder looks like this (it's a bit more complicated since it select the correct constructor based on the user input):
var builder = new SpiralBuilder( data );
builder.startDisplaying();
Now come the "conversion part". I read quite a lot about this, from Douglas Crockford's article, to parts of the Eloquent Javascript. In Aadit M Shah's comment, he proposes a structure which would look like this:
var svgBuilder = {
data: [],
xCoord: 0, // ?
create: function( dataset ) {
var svgBuilder= Object.create(this);
svgBuilder.data = dataset;
return svgBuilder;
},
startDisplaying: function() {
// stuff
}
}
However, at this point, I'm stuck. Firstly (technical question), can I declare variables (data, xCoord) without initialising them in this pattern? Just like a this.data;? Secondly, how am I then suppose to create the inheritances? I simply manually put the corresponding functions in the prototype? Something like:
var spiralBuilder = builder.create( dataset );
spiralBuilder.prototype.displayElements = function() {
// Code to display the elements of a spiral
};
spiralBuilder.displayElements();
If I am correct, this mean that in the script calling the builder, instead of selecting the correct constructor (which won't exist anymore), I'll have to add/modify the methods in the prototype of a single builder instance. Is it how things should be done?
Or should I try to design my code in a completly different way? If it's the case, could you give me some advices/references for this?
can I declare variables (data, xCoord) without initialising them in this pattern?
var svgBuilder = {
//removed data here as it's only going to shadowed
// on creation, defaults on prototype can be done
// if value is immutable and it's usually not shadowed later
create: function( dataset, xcoord ) {
var svgBuilder= Object.create(this);
svgBuilder.data = dataset;//instance variable
svgBuilder.xcoord = xcoord;//instance variable
return svgBuilder;
},
startDisplaying: function() {
// stuff
},
constructor : svgBuilder.create
};
I know I rarely do this in my samples but when creating instances or invoking functions it is generally better to pass parameter objects.
At some point in time you may change things here or there and you don't want to change many places in your code.
In the first couple of examples you're not using prototype at all. Every member is declared as this.something in the constructor function so is an instance specific member.
A builder can be used but when you're comfortable declaring your constructor functions, your prototype, mix ins and maybe statics then all you need is a helper function for inheritance and mix ins.
Introduction to prototype can be found here. It also goes into inheritance, mix ins, overriding, calling super and the this variable. A copy of the introduction follows:
Constructor function introduction
You can use a function as a constructor to create objects, if the constructor function is named Person then the object(s) created with that constructor are instances of Person.
var Person = function(name){
this.name = name;
};
Person.prototype.walk=function(){
this.step().step().step();
};
var bob = new Person("Bob");
Person is the constructor function as it's an object (as most anything else in JavaScript) you can give it properties as well like: Person.static="something" this is good for static members related to Person like:
Person.HOMETOWN=22;
var ben = new Person("Ben");
ben.set(Person.HOMETOWN,"NY");
ben.get(Person.HOMETOWN);//generic get function what do you thing it'll get for ben?
ben.get(22);//maybe gets the same thing but difficult to guess
When you crate an instance using Person you have to use the new keyword:
var bob = new Person("Bob");console.log(bob.name);//=Bob
var ben = new Person("Ben");console.log(bob.name);//=Ben
The property/member name is instance specific, it's different for bob and ben
The member walk is shared for all instances bob and ben are instances of Person so they share the walk member (bob.walk===ben.walk).
bob.walk();ben.walk();
Because walk() could not be found on bob direcly JavaScript will look for it in the Person.prototype as this is the constructor of bob. If it can't be found there it'll look on Function.prototype because Person's constructor is Function. Function's constructor is Object so the last thing it will look is on Object.prototype. This is called the prototype chain.
Even though bob, ben and all other created Person instances share walk the function will behave differently per instance because in the walk function it uses this. The value of this will be the invoking object; for now let's say it's the current instance so for bob.walk() "this" will be bob. (more on "this" and the invoking object later).
If ben was waiting for a red light and and bob was at a green light; then you'll invoke walk() on both ben and bob obviously something different would happen to ben and bob.
Shadowing members happens when we do something like ben.walk=22, even though bob and ben share walk the assignment of 22 to ben.walk will not affect bob.walk. This is because that statement will create a member called walk on ben directly and assign it a value of 22. There will be 2 different walk members: ben.walk and Person.prototype.walk.
When asking for bob.walk you'll get the Person.prototype.walk function because walk could not be found on bob. Asking for ben.walk however will get you the value 22 because the member walk has been created on ben and since JavaScript found walk on ben it will not look in the Person.prototype.
So assignment of a member would cause JavaScript to not look it up in the prototype chain and assign value to that. Instead it would assign the value to an already existing member of the object instance or create it and then assign he value to it.
The next part (More about prototype) will explain this with sample code and demonstrate how to inherit.
Here I am trying to understand few concepts of inheritance in javascript.I have created person class and trying to inherit it in Customer class.
var Person = function(name) {
this.name = name;
};
Person.prototype.getName = function() {
return this.name;
};
Person.prototype.sayMyName = function() {
alert('Hello, my name is ' + this.getName());
};
var Customer = function(name) {
this.name = name;
};
Customer.prototype = new Person();
var myCustomer = new Customer('Dream Inc.');
myCustomer.sayMyName();
Every time a new object gets created ,javascript engine basically calls prototype's constructor. here I am trying to understand few things:
if Customer prototype is referring to Person object.So creation of new Customer object should contain only Person property/Method not the Customer property/Method.How Customer property get attached to the new Customer object (myCustomer)?
Am I missing some javascript concept here?
Here I am trying to understand few concepts of inheritance in javascript.I have created person class and trying to inherit it in Customer class.
Well then you sure have lost your way quickly. There are no classes in prototypal inheritance.
That's the whole point! :-)
Using .prototype and new Function() syntax isn't a very explicit way to leverage prototypal inheritance.
Consider using Object.create instead of new - this way allows you to directly say which object is supposed to be which's prototype. It's more straightforward and you're likely to grasp the idea of prototypes faster this way.
Also, if you want to have longer prototype chains, then this method will certainly be more comfortable to use.
You defined Person and Customer, and then set Customer's prototype to a Person instance. So, your chain looks like this:
myCustomer (a Customer instance)
Customer prototype (a Person instance)
Person prototype (a plain object)
Indeed, myCustomer is a Customer instance as it has Customer's prototype in its chain. It's not the same thing as a direct Person instance. The latter would not have Customer's prototype in the chain.
if Customer prototype is referring to Person object and so on creation new Customer object should contain only Person property/Method not Customer property/Method.
Yes. Your newly created Customer object inherits from the Person instance in Customer.prototype. As you have neither added properties to that prototype object, nor create properties to your instance in the Customer constructor, your customer contains only the person's properties.
How Customer property get attached to the new Customer object (myCustomer)?
Do it in the constructor function:
function Customer (){
this.customer_property = someValue;
}
This code is executed each time an instance is created via new. If you don't need that, you can just add the methods etc. to the Customer.prototype object.
Also have a look at What is the reason [not] to use the 'new' keyword here? - you should not instantiate a Person for the prototype object - why should all customers inherit its name etc? Use
function Customer(name) {
Person.call(this, name); // apply Person constructor on this instance
// for creating own properties (and privileged methodes)
// custom Customer code
}
Customer.prototype = Object.create(Person.prototype);
Customer.prototype.someMethod = … // Customer-specific prototype things
I think the confusion lies in saying "javascript engine basically calls prototype's constructor". For a new instance of your Customer, Javascript will create a new object, set the prototype to the Person object you've designated, then call your Customer constructor function to customize the object (this is the illusion of "class" in JS). There's no re-calling of the prototype constructor function. So, your fields/methods for Customer are set, in your Customer constructor.
When a customer object has a method/field referenced after construction, the javascript engine will try to find it in the fields/methods that were set via your constructor (or in code manipulating the object downstream of the constructor call). If it can't, it will look to the prototype object attached to find the method/field. In this way are both the Customer fields/methods available and the "superclass" fields/methods.