1

I am learning the js prototype, and I am wondering if there are any differences between the following two segment?

Segment1:

function SuperType(){
 this.color=["blue","yellow"];
}
function SubType(){
} 
Subtype.prototype = new SuperType();

Segment2:

function SuperType(){
 this.color=["blue","yellow"];
}
function SubType(){
 SuperType.call(this);
} 

and if the above two does the same thing, then why some codes bother to do this:

function SubType(){
 SuperType.call(this); 
 }
SubType.prototype=new SuperType(); 
asked Apr 20, 2014 at 19:07
1

4 Answers 4

2

Yes, there are differences.

In Segment 1, the subclass SubType does not call the constructor of SuperType so it never gets executed. Segment 1 is not a correct general purpose way to inherit from another object.

In Segment 2, the subclass SubType does call the constructor of SuperType so the statement this.color=["blue","yellow"]; gets executed, but the prototype is not set appropriately so any prototype items that SuperType might have had are not inherited. Segment 2 is not a correct general purpose way to inherit from another object.

Segment 1 would work properly if there was no code in the SuperType constructor (not the case in your example). As you show it, because the SuperType() constructor is not called, this.color would only be in the prototype and thus the same array would be shared by all instances which is generally NOT what you want. Calling the constructor properly would give every instance it's own copy of this.color, not a shared copy.

Segment 2 would work properly if nothing was added to the SuperType prototype and there are no constructor arguments for SuperType (happens to be the case in your example, but not a good general practice).

Neither is a good general purpose way of doing things.


Your last option is the proper general purpose way to do things because it both inherits from the prototype AND it executes the constructor of the inherited object.


The most general purpose way also passes any constructor arguments to the inherited object using .apply(this, arguments) like this and initializes its own prototype and sets it's constructor property.

// define base object constructor
function SuperType(){
 this.color=["blue","yellow"];
}
// define base object methods on the prototype
SuperType.prototype.foo = function() {};
// ---------------------------------------------------------------------------
// define object that wants to inherit from the SuperType object
function SubType() {
 // call base object constructor with all arguments that might have been passed
 SuperType.apply(this, arguments); 
}
// set prototype for this object to point to base object
// so we inherit any items set on the base object's prototype
SubType.prototype = new SuperType();
// reset constructor to point to this object not to SuperType
SubType.prototype.constructor = SubType;
// define any methods of this object by adding them to the prototype
SubType.prototype.myMethod = function() {};

If you are willing to only support IE9 and above, then you should change this line:

SubType.prototype = new SuperType();

to this:

SubType.prototype = Object.create(SuperType.prototype);

This avoids calling the SuperType() constructor in order to just get an object to use for the prototype. In most cases this really doesn't matter, but in cases where the constructor has side effects outside of just initializing it's own properties, it can matter.

answered Apr 20, 2014 at 19:10
Sign up to request clarification or add additional context in comments.

10 Comments

@ThorstenArtner'Austria' - Object.create() is a better to go if you are willing to only support IE9 and above. But, in this case (and in most cases), there is no downside to doing it this way. The object will end up with the exact same properties either way. Please explain any practical difference in the OP's case or in any common case.
@ThorstenArtner'Austria' - I've already read your answer. You haven't explained any practical consequences to doing it the way I proposed (so what if there's an extra copy of something in the prototype - it doesn't have any practical consequences in this example). In any case, I've also added a note to my answer about using Object.create() instead if you are willing to only support IE9 and above.
the problems happen when people forget to call the super constructor than the variables are still defined in the instances but not as own properties of the instances. and the second thing is. if you have more complexer programming and inheritance you have defined variables in the prototypes where you dont need it and also you are executing constructors where is no need of -> takes time
thanks for your detailed answer! but what does it mean by "the statement this.color=["blue","yellow"] is not executed?"if I do var instance1= new SubType(); and do console.log(instance1.color), I can still see the color is not null
@ThorstenArtner'Austria' - yep, that would be true - you would want to use Object.create() or a polyfill for it when setting up the prototype or make the object require an .init() call for that kind of stuff which is another common work-around. The point is that the base object constructor should be called in construction of the derived object. Let's try to stay on point here.
|
1

you should not set prototype inheritance with

 SubType.prototype=new SuperType (); 

because there can be problems.

if you do that like this, the prototype of SubType would also inherit the property color as own property of the SubType prototype, because the constructor is worked through. Every new instance of subType has then a reference to the color property in the prototype and is not an own property of the instance itself, this is finally not what you want because you only want to inherit the prototype. the luck is that after calling the super constructer every instance gets an own color property , but the color property is still also defined in the prototype. there is no need

so to really inherit only the prototype you should use Object.create or do a workaround like this.

function SuperType()
 {
 if (SuperType.doNotConstruct) return;
 this.color=["blue","yellow"];
 }
function SubType()
 {
 SuperType.call (this);
 } 
SuperType.doNotConstruct=true;
SubType.prototype = new SuperType();
SuperType.doNotConstruct=false;
SubType.prototype.constructor=SubType;

second way - better way - because no if Statement in the constructor is needed

function SuperType()
 {
 this.color=["blue","yellow"];
 }
function SubType()
 {
 SuperType.call (this);
 } 
var CLASS=function () {}
CLASS.prototype=SuperType.prototype;
SubType.prototype=new CLASS ();
SubType.prototype.constructor=SubType;
answered Apr 20, 2014 at 19:40

1 Comment

It must be SuperType.doNotConstruct=true;. And what is inheritation?
0

In segment 1 the prototype gets set correctly but the constructor function of SuperType never gets called.

At the start of segment 2 the constructor function of the SuperType gets called but the prototype is not set.

The last example is correct because it sets up the prototype correctly as well as calls the SuperType's constructor function.

function SuperType() {
 // Do some stuff.
}
function SubType() {
 SuperType.apply(this, arguments);
}
SubType.prototype = new SuperType();
answered Apr 20, 2014 at 19:12

1 Comment

Please give reasoning. @ThorstenArtner'Austria'
0

@blake try the following - this will show a problem when people forget to call the super constructor and do inheritation with ...prototype=new constructor

function SuperType()
 {
 this.color=["blue","yellow"];
 }
SuperType.prototype.addColor=function (name)
 {
 this.color.push ("red");
 }
function SubType () {}
SubType.prototype=new SuperType ();
var a=new SubType ();
var b=new SubType ();
a.addColor ("red");
console.log (a.color);
console.log (b.color);
answered Apr 20, 2014 at 20:35

7 Comments

So you're trying to train the OP NOT to call the base class constructor. Sure, it doesn't make a difference in this case, but I know of no site that teaches this as a good design pattern or the preferred practice.
thats for Blake (its about how problems can build up) because he wrote thanks for your detailed answer! but what does it mean by "the statement this.color=["blue","yellow"] is not executed?"if I do var instance1= new SubType(); and do console.log(instance1.color), I can still see the color is not null – Blake 2 hours ago and what is the difference if constructor is called or not? – Blake 2 hours ago this is not a way to do it, it shows how it should not be done... the second way i edited in my first post
OK, imagine the SuperType constructor requires an argument. How does this design pattern work then?
i dont know where this discussion goes to now, because we wrote comments above and now here. do you want to talk about the problems which can happen here, or do you want to talk about the second way i edited in my first answer see please write comments above
I think the OP's question has been answered. I just don't think we should be "teaching" methods that don't call the base constructor because those are not general purpose solutions that will always work.
|

Your Answer

Draft saved
Draft discarded

Sign up or log in

Sign up using Google
Sign up using Email and Password

Post as a guest

Required, but never shown

Post as a guest

Required, but never shown

By clicking "Post Your Answer", you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.