JavaScript adopts a radically different take on inheritance from what one is perhaps
used to coming from an object oriented, statically typed language world such as
C++, C# or Java. In the typical OO static language, inheritance is applied to "classes"
which are essentially templates for how an object instance should be laid out in
memory at runtime. JavaScript however is weakly typed, i.e. pretty much everything
is an "object". How will inheritance work out in a weakly typed dynamic language
such as JavaScript? Enter "prototypal inheritance"!
Prototypal Inheritance
Somewhat counter-intuitively, inheritance in JavaScript applies to object instances
instead of types. I know that sounds kind of weird but once we see how it works,
it actually turns out to be quite elegant. Every object has a hidden default member
called its "prototype". The prototype of an object is a simple reference to another
object which in turn has its own prototype reference to yet another object. Here's
a picture illustrating this:
Here, object1's prototype points to object2 and object2's
prototype points to the prototype of the JavaScript Object type (part
of the JavaScript library). The Object type's prototype does not
in turn point to yet another object and is always null thereby making
it the root object in the inheritance hierarchy.
Whenever you attempt to access a member field or method on an object the JavaScript
runtime attempts to locate the member directly on the object. If the lookup fails
then it attempts to locate the member in the object's prototype and continues
to walk the prototype chain till the member is found (if the member ends up never
being found then you get a syntax error or an "undefined" reference depending on
the context). Here's a pseudo-implementation of member lookup implemented in JavaScript:
//
// dereferences the member identified by "memid"
// if it exists directly on the object; returns
// "null" otherwise
//
Object.prototype.getOwnProperty = function (memid) {
if (this.hasOwnProperty(memid))
return this[memid];
return null;
};
//
// lookup member property/method called "memid" on object
// "obj"; walks the prototype inheritance chain till member
// is found; returns "null" if member is not found
//
function lookup(obj, memid) {
var mem = obj.getOwnProperty(memid);
while (!mem) {
obj = Object.getPrototypeOf(obj);
if (!obj)
break;
mem = obj.getOwnProperty(memid);
}
return mem;
}
So how does prototypal inheritance work?
So how exactly do you do prototypal inheritance? The basic idea is that new objects
are created by copying the structure of an existing prototype object (see prototype creational design pattern). Here's another bit
of JavaScript pseudo-code that shows how this might work:
var person_proto = {
name: "no name",
age: 0
};
var o = {};
o.prototype = person_proto; // this won't actually work!
Please note that the above actually won't work the way you intend it to if you run
it (it will simply create a new property called "prototype" on "o"!).
The object "o"'s prototype will not get set. In fact JavaScript does
not provide a mechanism to assign a value to an object instance's prototype (Mozilla
and WebKit browsers do however permit this via a special extension property named
__proto__ - but this is not a part of the ECMAScript standard and should
not be relied upon). Having said that, in essence, what has been given above is
what happens when you inherit prototypally. Here, "o" is a new object
whose prototype is a reference to another object (person_proto). When you access the name
property like so:
print(o.name);
The JavaScript engine would actually resolve the "name" property on the object's
prototype since the object itself does not have a property called "name". But since
the JavaScript language does not allow one to assign the prototype on an object
instance how can we achieve this sort of inheritance in a standards compliant manner?
Douglas Crockford
has discussed precisely this in his blog post on prototypal inheritance. His solution basically
takes advantage of the fact that while you cannot assign the prototype of an object
instance you can in fact assign the prototype on a Function object.
Here's a utility routine that allows us to inherit prototypally from another object.
function inherit(o) {
function F() {}
F.prototype = o;
return new F();
}
And here's some code that shows how we'd use this function to inherit from the
person_proto object defined in the previous snippet:
var gender_person = inherit(person_proto);
gender_person.gender = "f";
Note that I have also extended the gender_person object by tacking
on the gender property to it. Imagine that I wish to inherit another
object from gender_person and add a "married" boolean
member field to it. Here's how I'd go about it.
var marital_person = inherit(gender_person);
marital_person.married = false;
Here's the inheritance chain depicted pictorially:
Note that the inheritance relationship is completely between object instances and
not types. Also note the following aspects of this style of programming:
- Each "inherit" operation is essentially an object instantiation.
- Each "inherit" seems to be always accompanied with the definition of new members on
the new object.
ECMAScript
version 5 therefore adds a new function called Object.create that does exactly this. Here's
the same example done using Object.create instead of our homebrewed
inherit.
//
// create basic person prototype object; this
// object's prototype will be equal to Object.prototype
//
var person_proto = {
name: "no name",
age: 0
};
//
// inherit from "person_proto" and add a new member
// field called "gender"
//
var gender_person = Object.create(person_proto, {
gender: {
value: "f",
writable: true,
enumerable: true,
configurable: true
}
});
//
// inherit from "gender_person" and add a new member
// field called "married"
//
var marital_person = Object.create(gender_person, {
married: {
value: false,
writable: true,
enumerable: true,
configurable: true
}
});
for(var i in marital_person)
print(sprintf("marital_person.%s = %s", i, marital_person[i]));
Here's the output we get when we run this snippet (you can try it in the Eval console yourself if you like - just make sure that
you're running a browser that has support for ECMAScript 5 - which is most modern
browsers).
marital_person.married = false
marital_person.gender = f
marital_person.name = no name
marital_person.age = 0
Its interesting to observe that when you use for...in to reflect on
an object it seems to walk the prototype chain bottom up. In the output above, it
printed the properties on marital_person first, then gender_person
and finally proto_person. This prototypal nature of the language is
what enables you to do powerful things such as adding new members to even core library
types such as Object, String, Array etc.
When you add a new trim function to String.prototype for
instance, it automagically shows up not just on new string objects created henceforth
but on all string instances that are alive at that point in time! This is made possible
because during the actual member resolution process the runtime walks the prototype
chain to locate it before giving up.
But I want my new!
What I have described so far is the way inheritance was designed to work in JavaScript.
Desiring to cater to developers who are familiar with static languages such as Java
(which was really taking off at the time JavaScript was introduced), Netscape decided
to make the unfortunate choice of simulating classical object instantiation and
type inheritance behavior by introducing syntactic sugar (or maybe it should be called syntactic salt!)
that hid the prototypal nature from the programmer. The end result is a construct
that ends up being not quite classical inheritance while deliberately misleading
the developer on what's actually happening under the covers! Its fairly common to
see code such as the following today:
function Person(n, a) {
this.name = n;
this.age = a;
}
var p = new Person("Foo", 10);
Its interesting to see what is actually happening under the covers when you "new"
up an object. Here's the last line of the snippet given above "expanded" to the
actual instructions being run under the covers in pseudocode form.
var p = {}; // create empty object
p.prototype = Person.prototype; // assign prototype (as before
// this won't actually set the
// prototype)
Person.call(p, "Foo", 10); // run constructor on object
Briefly, an empty object gets created and its prototype gets assigned to Person's
prototype and the constructor function is invoked using the new object as its context. It is
self-evident that there really isn't a "type" called "Person". The language just
allows the developer to pretend like there is! In fact it even provides an "instanceof"
operator that you can use to verify if an object is an instance of a particular "type". Here's how
you use it
function Person(n, a) {
this.name = n;
this.age = a;
}
var p = new Person("Foo", 10);
print(p instanceof Person); // prints "true"
What the operator does is to check if the prototype of the constructor function (Person in the snippet above) figures in the object's
prototype chain. Here's a possible naive implementation of the "instanceof" operator as a
JavaScript function with some sample usage:
function instanceOf(o, t) {
if(typeof(t) !== "function")
throw "Pass a Function object for type name.";
if(typeof(o) !== "object")
throw "Object must not be a primitive type.";
var proto = t.prototype;
var op = Object.getPrototypeOf(o);
while(op) {
if(proto === op)
return true;
op = Object.getPrototypeOf(op);
}
return false;
}
function Person(n, a) {
this.name = n;
this.age = a;
}
var p = new Person("Foo", 10);
print(instanceOf(p, Person)); // prints "true"
With that we conclude our brief review of how inheritance was designed to work in
JavaScript. I have deliberately not discussed how we can simulate classical inheritance
patterns in JavaScript though that is very much possible. Douglas Crockford has
covered this topic in this article but he ended up adding the following footnote
to it - presumably many years after he'd written that article (emphasis mine):
I have been writing JavaScript for 8 years now, and I have never once found need
to use an uber function. The super idea is fairly important in the classical pattern,
but it appears to be unnecessary in the prototypal and functional patterns. I now
see my early attempts to support the classical model in JavaScript as a mistake.
