JavaScript: Not your father's inheritance model - Part 1
This post is part of a series called JavaScript Demystified.

This particular chapter is further divided in two parts. Read Part 2.

In a previous installment in this series we saw how we could create constructor functions in JavaScript. Back then I just mentioned that we don't have classes in JavaScript and that there's this weird prototype property in every object.

Let's dig into those concepts a little more and try to understand how inheritance is achieved in JavaScript.

Inheritance as we often know it

For myself and probably the majority of you reading this blog, inheritance in an Object Oriented programming language is directly associated with the concept of classes.

When we work with C#, VB, Java, Ruby, and many other popular programming languages, each of our objects is of some type, which is represented by a class. Our objects automatically inherit functionality from their associated class often called base or super class, and any other classes that the base class itself is associated with (i.e. derives from.)

That's nothing new to you, I'm sure. I'm just re-hashing that in the previous paragraph to make a comparison later. Let's call this model class-based inheritance.

That's not the end of the story

This may come as a surprise to some people, but class-based inheritance is not the only way to obtain Object Oriented inheritance (by saying Object Oriented I automatically excluded those of you that thought Copy/Paste Inheritance was one of them.)

It just so happens that the JavaScript language designers chose another inheritance model. And they are not alone in that choice. By opting for a prototype-based inheritance model , JavaScript joined the ranks of other programming languages such as Self , Lua , and Agora.

The prototype is the king

Objects in JavaScript don't inherit from classes; they inherit straight from other objects. The object they inherit from is called their Prototype (I'm using a capital P here to avoid confusion down the line.) The object's Prototype is assigned right at construction time.

You may be intrigued and say: But when I create my objects I don't remember specifying any Prototype stuff. What gives?

Let's see what happens then. When you create a plain Object using either of the following syntaxes

var obj1 = new Object();
obj1.name = 'box'
//or
var obj2 = { name: 'door' };

JavaScript will automatically assign a Prototype to each of these objects. This prototype will be Object.prototype.

Similarly, let's see what happens with a few of the other object types in JavaScript.

The Prototype objects is how every object in JavaScript is born with inherited functionality. For example, the substring() method that every String object has is a method defined in the object String.Prototype.

The prototype objects themselves also inherit from Object.prototype, that's how every object of any type has a toString() method.

When you try to access 1234.constructor, as an example, the runtime will look for a constructor property on our object (the number 1234). It doesn't have one so the next step taken is to check if that object's Prototype has it. The Prototype for 1234 is Number.prototype and it doesn't have that property either. The runtime then looks on the Prototype of Number.prototype, which is Object.prototype. That last object does have a constructor property, so that is returned. If it didn't, undefined would have been returned instead.

In Part 2 we will see how to create our own Prototypes.


Posted 06-12-2009 6:03 PM by sergiopereira

[Advertisement]

Comments

DotNetShoutout wrote JavaScript: Not your father's inheritance model - Part 1 - Sergio Pereira - Devlicio.us
on 06-13-2009 12:16 AM

Thank you for submitting this cool story - Trackback from DotNetShoutout

on 06-15-2009 10:31 AM

WF/Orcas Sequential and Flowchart modeling styles Introduction to Workflow Tracking in .NET 4.0 Beta 1 Building Applications for Orcas - With the "Oslo" May 09 CTP, the MSDN Library now contains a number of additional topics covering more of

Michael .H wrote re: JavaScript: Not your father's inheritance model - Part 1
on 12-10-2009 12:30 PM

But this is not to close to the classical inheritance principles. I have notices the title of the article. There are other ways of implementing this, ways which are closer to the classical pattern (Crockford, Base2, etc). Even in those cases there are things which should be added, like how parameters are passed from derived class to base class, on which members do you have access when your chain call reaches the base class, checking the number of arguments for constructors, etc. I tried also a different technique, it's a mixture of existing ones, Crockford, Base2 of Dean. It supports different class definitions and private members.

<a href="dotnetcaffe.blogspot.com/.../a>

sergiopereira wrote re: JavaScript: Not your father's inheritance model - Part 1
on 12-10-2009 1:57 PM

@Michael, I believe that the more you try to implement classical inheritance in JS, the more frustrated you'll be. JS may eventually support classical inheritance, until then my personal preference is to embrace prototypal inheritance and not try to work around it.

Michael .H wrote re: JavaScript: Not your father's inheritance model - Part 1
on 12-11-2009 7:38 AM

@sergiopereira not really, it really depends from what angle you see it. It's true, it requires more work when you design the inheritance pattern and you also lose some performance related to memory. I would not consider the performance an issue as long as you do not start creating thousands and thousands objects with a deep level of inheritance. The gain is in a more natural approach to OO inheritance with all it facilities and a clean way of constructing the classes.

sergiopereira wrote re: JavaScript: Not your father's inheritance model - Part 1
on 12-11-2009 9:07 AM

@Michael, we clearly have different definitions for "frustration" and "natural". Of course I understand the reasoning behind trying to implement classical inheritance in JS (I've been deeply involved with Prototype.js for example.) But let's just leave it at that, agreeing to disagree.

Michael .H wrote re: JavaScript: Not your father's inheritance model - Part 1
on 12-11-2009 10:27 AM

Ok, got it :D. But can you please explain me what do you understand by 'frustration', in your case?

sergiopereira wrote re: JavaScript: Not your father's inheritance model - Part 1
on 12-11-2009 12:19 PM

@Michael. I'd rather not, otherwise we would only prolong this unnecessary discussion. Let me just say that your previous comments contained some of those for me (and maybe just for me).

Sergio Pereira wrote Guided Tour: jQuery - Array wannabes
on 12-23-2009 11:16 AM

This post is part of a series called the Guided Tours . In this second installment we are still looking

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)