Jump to content

prototypal inheritance


Ramu26

Recommended Posts

Hi,

Prototypal inheritance advocates Approach: 2, where we wrap the parent prototype with new object, augment the constructor and then assign it to subType. However, in Approach : 1 I havedirectly assigned the prototype both instanceof and prototype checks have passed.

function Person(){}Person.prototype.sayHi=function(){    return "hi";}function SubPerson(){}//Approach : 1 directly assign the prototypeSubPerson.prototype= Person.prototype; //Approach : 2 wrap it with the other object//var newObject= Object.create(Person.prototype); //newObject.constructor=SubPerson;//SubPerson.prototype=newObject;var subPersonInstance= new SubPerson();console.log( (subPersonInstance instanceof  SubPerson) +" "+ (subPersonInstance instanceof Person));console.log( (SubPerson.prototype.isPrototypeOf(subPersonInstance)) +" "+ (Person.prototype.isPrototypeOf(subPersonInstance)));

In that case, we can go by Approach : 1 right ? why to wrap it with new Object.Thanks

Link to comment
Share on other sites

You would create a new object for the SubPerson's prototype because if you don't, any changes to SubPerson's prototype will also modify Person's prototype. They're both pointing to the same object.

Link to comment
Share on other sites

If I have only shared information in prototype and specifics at the instance level, I can choose to use Supertype.call() to inherit the specifics/instance level information. In that case, I can directly reference the prototype right ?

Link to comment
Share on other sites

1st off, Approach #1 appears to work because you have nothing new happening in the SubPerson constructor if SubPerson had its own constructor it would never be called, and SubPerson would never initialize correctly. Plus Approach #2 can not only setup inheritance, but also enables you to create some fancy getter/setter functions that you simply can't do otherwise in the javascript language. Approach #2 grants you far more control in defining a subclass than Approach 1 ever can. in response to your 2nd post, You can always directly reference the prototype chain, the problem is in practice more often than not you shouldn't as doing so cause more work down the road. The way prototyping works is by levels of specificity, in a chain of Prototypes. Here is what I mean.

  subPersonInstance           |          {/*nothing defined outside the SubPerson subclass that is attached to this instance*/}         v               SubPerson         |          {/* no other variables defined in this chain*/         |            prototype:Person         v          }      Person         |          {         |            sayHi:function(){return "hi"}         |            prototype:Function         v          }     Function         |          { /*All of the Function prototype variables*/          |            prototype:Object         v          }      Object                    { /*All of the Object prototype variables*/                       prototype:null                    }

now Person has the function "sayHi", but you don't re-define that function in the instance or SubPerson, so as you said its shared info. when you have subPersonInstance run "sayHi" first javascript will look in subPersonInstance to see if its defined there, its not so it looks at the next object in the prototype chain, SubPerson, to find the defined function, not deifned there either, which it continues on the prototype chain to Person where it is defined. it stops there and runs the function it found as expected if say you want a Supertype.call effect then you would write another sayHi function (for the sake of example) inside the SubPerson prototype then you would have written it like this...

SubPerson.prototype = Object.create(Person.prototype,{    sayHi:{              value:function(){                  return Person.prototype.sayHi.apply(this,arguments)+" there!";                  //technically you don't need to use "apply" since the super function doesn't use arguments, but                  //this code isn't that complex in the 1st place and is universal no matter how many arguments                   //the super function has              },              enumerable:true,              configurable:true,              writable:true          }    });

now SubPersonInstance will say "hi there!" instead of simply "hi".

 

 

I should empathize that its far more important understand and use Polymorphism and Composition than simple inheritance when you want to build any OOP application of merit.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...