Of course this presents itself as a Catch-22. On one hand we know if we were to forget our phone at a coffee shop or a public library (or even worse lose our phone), it would prevent someone from getting to know pretty much everything there is to know about us. On the other hand it also prevents a good Samaritan from returning the phone to us in the event they find it.

Furthermore, locking the phone also obstructs emergency services from getting a contact person in the event of an unfortunate accident.

So what does one do?

For what it is worth, there are tons of ICE apps out there for the iPhone (or any other smart phone). All of these apps record relevant parts of our medical history (such as blood type, current medications and any existing allergies) allowing emergency services to quickly determine how to respond. Furthermore these allow us to make the info page as the Lock screen so the paramedic does not need to unlock the phone in order to get to that information.

Needless to say these serve well as our “In case of Lost Phone” application because they list emergency contacts as well.

One concern with the lock screens these apps generate is their looks :–/ Of course this may be a tad short-sighted especially in light of the medical concern, but that does not prevent us from trying, right? :)

Allow me to admit that I am a big fan (and long time lurker) on both Lifehacker and App Chronicles (especially they Apps Gone Free page). A while back Lifehacker posted an article that got me thinking on creative ways to add ICE information on the home screen. Soon after seeing that article App Chronicles posted that Typic Pro – Photo Text Editor that had gone free for a day and I managed to snap it up. Typic Pro allows us to add captions and design elements (like banners and frames) to our photographs which is exactly what we need.

Game on.

First thing we do is was open up the Typic Pro which presents us with an option to take a photo, or select one from our photo library. We will opt to take a new picture. The idea here was to get a completely black background, so cover up the camera lens with a finger, or rest it on any opaque surface to block out all light (be sure to switch off the flash for this) and click. There! A completely black background.

Then, go to town with it. Typic Pro allows us to set (at most two) captions on the picture, pick font, font colors etc. Here’s an example.

Let us try a few more. Here is another one

Of course we need to be careful with how far we take this. Typic Pro allows us to pick one of many available fonts from a deck but the idea is to keep it legible. After all the purpose of this exercise is that anyone finding the phone should be able to read it without any difficulty.

Typic Pro only allows a maximum of two captions per image which can be a tad restrictive at times. Fortunately we can easily work around this. Simply line up the first two captions to accommodate for more, save the image, then open that image up again in Typic Pro and add two more!

As an example we can start here

Notice now there is some some space left on the right-hand side of the name to allow for a third caption. Open the image up again in Typic Pro and add another caption.

Pretty sweet, right? :)

So there we have it. A nice way to create a lock screen wallpaper. Here is one in it’s full glory

A few final points of note. One, bear in mind the idea is legibility first and foremost. Second, the image will need adjusting prior to setting it as the wallpaper especially if the text is dangerously close to the bottom edge of the screen. Third we can always use an image as a background, but since our topmost priority is legibility a blank background works best.

Finally, we must realize that ICE applications and cards have their place. While this is a great experiment in cosmetics it cannot (and should not) come in the way of our well-being. Do what is right, aesthetics be damned.

With that said, be careful and safe out there.

[Full disclaimer: I am in no way affiliated with Lifehacker, App Chronicles or Typic Pro apart from being a happy customer. All the links in this article are affiliate free]

In the first installment of this series, we discussed objects and functions in JavaScript. In this second, and final, installment in this series, we will go a bit further and see how functions are used as “instance factories” or constructors to create objects. We will see how we can use these “constructors” to not only instantiate new instances, but also endow new objects with a predefined set of properties applicable to that “class” of objects (much like Java classes). Finally, we will put it all together to build our own hierarchy. We will also see some potential potholes and how to avoid them in your code.

In our previous discussion, we learned about JavaScript objects and that they have a few magical properties adorned upon them, specifically the constructor property and the __proto__ property. We also noted that all objects (except Object.prototype) participate in a hierarchy – by having their __proto__ property point (directly, or indirectly) to Object.prototype.

We also learned that JavaScript functions are objects themselves and have an additional property called prototype, which points to a plain old JavaScript object. This prototype object, just like any other JavaScript object, has a constructor property that points back to the function itself and it’s __proto__ property points to Object.prototype.

Before proceeding, I encourage you to fire up Google Chrome’s Console (or Firebug’s console) so that you can experiment with the code (See Part I to see how you can do this).

Also, I would like to include our last code snippet Listing 1 and its accompanying visualization Figure 1 from Part 1 just for reference purposes – we are going to need them for our discussion.

1
2
3
4
5
6

function Person(name) {
    // ignore the argument for this listing
}

console.log(Person.prototype); // evaluates to Person { }
console.log(typeof Person.prototype); // evaluates to "object"

Just like we discussed in Part 1, we are defining a function called Person. This function object has a prototype property that points to a simple JavaScript object, referred to as Person.prototype. This prototype has its own __proto__ property, which in turn points to Object.prototype, and a constructor property that points back to the Person function object. This hierarchy is visualized in Figure 1.

So that was our recap of Part 1. Ready to begin? Let’s go …

The Constructor Invocation Pattern

Let’s say we wanted to create a “class” of Person objects. These objects are to have a name, and should be polite to one another. Listing 2 is how we would declare and use the Person function to achieve this.

1
2
3
4
5
6
7
8
9
10
11
12
13

function Person(name) {
    this.name = name;
    this.sayHello = function(other) {
        return "Hello " + other.name + "! My name is " + this.name;
    }
}

// Using the 'Person' function as a "constructor"
var brendan = new Person("Brendan");
var douglas = new Person("Douglas");

console.log(brendan.name); // returns "Brendan"
console.log(brendan.sayHello(douglas)); // returns "Hello Douglas! My name is Brendan"

Some subtle, yet important things to note here. Our Person function object does not have an explicit return. Furthermore, within Person we are referring to some object as this. Lastly, we invoke the Person function with the new keyword. So what’s going on here?

JavaScript overloads the role of a function to act as a constructor when invoked with a new – this is called the “Constructor Invocation pattern”. When you do this, a new object pops into existence within the scope of the constructor, which you can refer to as this. Finally, the constructor evaluates to (that is “returns”) this newly created object.

Armed with that information, you can see what’s going on in Listing 2. When we invoke Person with the new keyword, JavaScript creates a new object. This object, which we can get a handle to using the this keyword within the scope of the Person constructor, is then adorned with the name property, and a sayHello method. sayHello can refer to that object’s name using this.name. Finally, Person returns this newly created object, which is assigned to the variable brendan. Essentially, brendan is an “instantiation” of the Person function. Another way to look at Person is to think of it as the “constructor” and the “class” all rolled into one.

I would like to point out that both brendan and douglas are JavaScript objects like any other – they both have __proto__ pointers but with one big difference – this.__proto__ (where this is the newly created object, so either brendan or douglas – See Figure 2) pointer points to Person.prototype, and not Object.prototype. Conceptually after evaluation, Listing 2 looks as shown in Figure 2.

Compare Figure 2 with Figure 1 and see how we have managed to intercept the __proto__ lookup chain. If we were to introduce sayGoodbye as a method in Person.prototype only brendan and douglas would see that method as part of the method lookup – all other objects that directly (or indirectly) inherit from Object.prototype are not affected! This allows us to define methods that apply only to a specific (in this case Person) “class” of objects. Pretty neat, right?

Let’s take it up another notch. We have the Person function defined, and consequently we get a Person.prototype. But suppose we realize we need to model Mammal, from which Person (and subsequently) brendan and douglas are to inherit from. How do we go about doing this? Think about this for a few minutes before taking a peek at Listing 3 (Hint: You have to figure out a way to make Person’s prototype point to Mammal’s prototype)

1
2
3
4
5
6
7
8
9
10

 // Tack this code on after Listing GAN-2 in your console window
 function Mammal() {}
 Mammal.prototype.nurture = function() {
     return "Care";
 };

 // this is where we rearrange the pointer
 Person.prototype.__proto__ = Mammal.prototype;

 console.log(brendan.nurture); // evaluates to "Care"

Here, Mammal is just another function, and has its own prototype. This prototype object is no different than Person.prototype in that it has a __proto__ property that points to Object.prototype. We then change Person.prototype to point to Mammal.prototype. See Figure 3 to see how this lays itself out (I have left out Object.prototype, but Mammal.prototype.__proto__ points to Object.prototype as indicated by the dashed arrow).

The key thing to understand and remember here is that the constructor functions are mere facilitators allowing us to create objects with their __proto__ property set correctly. It’s the objects themselves that intrinsically know who their “prototypes” are and enable function (and property) lookup.

There is another way to set the inheritance chain properly without resorting to what we did in Listing 3. In Part I of this series, we used Object.create to create a new object, but we passed null as an argument. Now that we know how we can use prototypes to enrich the inheritance chain, we will see how to use it. This argument, if supplied, tells JavaScript what the newly created object’s prototype should be. Consider Listing 4 to see how you can use this.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

var person = {
    sayHello: function(other) {
        return "Hello " + other.name + "! My name is " + this.name;
    }
};

// here 'person' becomes the 'prototype' for 'brendan'
var brendan = Object.create(person);
brendan.name = "Brendan";

var douglas = Object.create(person);
douglas.name = "Douglas";

brendan.sayHello(douglas); // evaluates to "Hello Douglas! My name is Brendan"

We create a person object that happens to have a sayHello method. We then use this object (Note: Not a function) as an argument to Object.create. Fundamentally, this is the same as Listing 2. The newly created person object serves as brendan’s __proto__ and everything works just as we saw earlier. This just gives us another way to correctly set the prototype chain up of any object.

Putting It To Good Use

Let’s consider two distinct problems and see if we can apply our new found knowledge to solve them. In functional programming, the map function is amongst the most used functions, not only in and of itself, but also as a building block for other higher-order functions. map allows you to apply a function to every element in a collection, thereby transforming each element in the collection, and returns a new collection with the transformed elements. Needless to say, the returned collection has the same size as the one supplied to map. We do this all the time in our Java code, albeit in an iterative fashion. Consider the Java code listed in Listing 5.

1
2
3
4
5
6
7
8
9
10
11

List<String> names = new ArrayList<String>(3) { {
    add("brendan");
    add("douglas");
    add("john");
} };
List<String> transformedNames = new ArrayList<String>(names.size());

// perform the map
for(String name: names) {
    transformedNames.add(name.toUpperCase());
}

As you can see from Listing 5, we apply the toUpperCase method to every element in the names list and add it to transformedNames. After this code executes, transformedNames will contain exactly three names, all uppercase.

If we were to do this in JavaScript, one approach would be to do as shown in Listing 6.

1
2
3
4
5
6
7
8
9
10
11
12
13

 function map(coll, f) {
     var ret = [];
     for(var i = 0; i < coll.length; i++) {
         ret.push(f(coll[i]));
     }
     return ret;
 }

 // just wrap toUpperCase. You can use apply instead
 // takes a single arg and uppercases it
 function myToUpperCase(str) { return str.toUpperCase(); }

 map(["brendan", "douglas", "john"], myToUpperCase); // return ["BRENDAN", "DOUGLAS", "JOHN"]

Notice that our map function takes another function as its argument, and for each element calls f passing it the n^th element of the array and pushes it on to the return array.

If you were to deliberate on this for a moment, it does seem a little smelly. The fact that map has to iterate over the collection seems like feature envy. What if we could have a map method on Array that would accept the transforming function and we could invoke that on any array? That would get rid of the smell. Think about what we discussed and see if you can figure out how to pull that off (before taking a look at Listing 7).

1
2
3
4
5
6
7
8
9
10
11

Array.prototype.map = function(f) {
    var ret = [];
    for(var i = 0; i < this.length; i++) {
        ret.push(f(this[i]));
    }
    return ret;
}

function myToUpperCase(str) { return str.toUpperCase(); }

["brendan", "douglas", "john"].map(myToUpperCase); // return ["BRENDAN", "DOUGLAS", "JOHN"]

We know that when we invoke a method on any object, JavaScript will go through the prototype chain until it finds the method or reaches Object.prototype and bails. All we have to do is get a handle to the __proto__ object of Array, or alternatively ask the Array function for its prototype (which is what we are doing in Listing 7) and tack on the map method. Done! Now, all arrays are blessed with a map method. Note that within the for loop in Listing 7, we refer to the array itself as this – since JavaScript is invoking the map method on an instance of an Array.

Consider another scenario. Let’s say that you wanted to keep tabs on how many Person objects were created during the execution of a program. The way we would do this in Java would be to create a static variable – essentially a variable that is the same across all instances of a class and increment it every time the Person constructor was invoked. How can we do that in JavaScript? Well, we know we have constructor functions that would be invoked with the new keyword, so that would be a good place to increment the counter. But where do we store the variable itself? Doing a this.counter++ won’t work because this within the context of a constructor function refers to the newly created object, making counter an instance variable.

But we also know that functions themselves are objects and can have properties of their own. Can we somehow make use of that? Take a look at Listing 8.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

function Person(name) {
    // equivalent to saying Person.counter
    // but more idiomatic
    this.constructor.counter++;
    this.name = name;
}

// init 'static' variable
Person.counter = 0;

brendan = new Person("Brendan");
douglas = new Person("Douglas");

console.log(Person.counter); // returns 2
// alternatively
console.log(brendan.constructor.counter); // also returns 2

If we were to glance back at Figure 3 you will notice that Person.prototype has a constructor property that points back to the its function (Person in this case). Within the context of the constructor function, this is the newly created object, which has its __proto__ property set to Person.prototype. When we ask this (for e.g brendan) for its constructor property, JavaScript looks within the newly created object and does not find it. So it does what we expect it to do – follow the __proto__ property up to Person.prototype which does have it, and hands us back a pointer to the Person function. We then ask it for its counter property (which we have initialized to 0) and increment it. Figure 4 illustrates the state of the system after Listing 8 finishes execution (note that I am not showing Object only to avoid clutter – that hierarchy remains the same in previous illustrations).

Of course, we could have just said Person.counter and get the same desired effect, but there might be times when you don’t know the constructor function of an object, so having the constructor property can prove to be really handy.

Words of Caution

Before we conclude this article, I would like to emphasize a few key points. Although __proto__ is a handy property for testing and illustrative purposes (in FireFox and Chrome), by no means should you rely on using (or even assume the existence of) this property in production code. The idiomatic way to getting the prototype of any object is to use the getPrototypeOf method supplied on Object (e.g. Object.getPrototypeOf(brendan)).

We have been naming our constructor functions (like Person and Mammal) with a capital “P” (and “M”) vs. lowercase letters as is the norm for function names in JavaScript. The reason for this is to highlight the fact that they are, in fact, constructors, and should be invoked with the new keyword. Not doing so will result in bad things happening. Constructor functions, as we noted earlier, do not have an explicit “return”, and often refer to this in their function bodies. What does it mean if we were to invoke a constructor function without the new keyword? Let’s take a quick look in Listing 9.

1
2
3
4
5
6
7
8
9
10
11
12
13

 function BadlyInvoked(villianiousArg) {
     this.villianiousProperty = villianiousArg;
     this.villianiousFunction = function() {
         return "Muhhhaahaa!";
     }
 }

 var villian = BadlyInvoked("The Joker");
 console.log(villian);  // evaluates to undefined

 // global domination
 console.log(villianiousProperty); // no object context
 console.log(villianiousFunction()); // nor here

Notice that you get no errors whatsoever. JavaScript happily chugs along executing the code, but villian evaluates to undefined. This is because BadlyInvoked does not return anything (and by default, JavaScript returns undefined). Furthermore, you can get to villianiousProperty and villianousFunction without a reference to villian. What happened was upon invocation, BadlyInvoked, did not create a new object, rather it acted as any other function would (remember that if you use the ‘Function Invocation’ pattern, that is invoke a function as a standalone, this is implicitly the “global object”). Therefore, this refers to the global object, which in the browser environment happens to be the window object. We just accidentally introduced two new properties on the window object. If these had been named anything less sinister (e.g. name) you would have just clobbered the global name property! Not to mention that your code will begin to throw all kinds of errors if you attempt to use villian in any way, because it is undefined!

Naming constructor functions with capital letters is idiomatic JavaScript, and the preferred convention as a way to alert fellow developers that this function should be invoked with the new keyword.

Conclusion

Phew! We have reached the end of our whirlwind tour inside JavaScript’s inheritance strategy and implementation. Although some of this may seem a little overwhelming, and perhaps even a tad confusing, hopefully I have given you a clear guide to a better “understanding” of the language and implementing your own inheritance hierarchies within JavaScript.

JavaScript is truly a powerful language. Couple prototypal inheritance with JavaScript’s dynamic nature (adding, removing and changing behavior at runtime), and you are one step closer to unleashing the power to write idiomatic, clean and most importantly, re-usable code within your applications.

Douglas Crockford refers to JavaScript as “Lisp in C’s Clothing” which gives us an inkling to it’s true power. Unfortunately JavaScript, a language that started with a rushed schedule to production and a specification that was buffeted with strong political winds at it’s inception, has often been “misunderstood”. Despite it’s unfortunate beginnings, amidst the stormy waters laden with many a pitfall like global variables, lie a few pearls of wisdom, of which one is prototypal inheritance. In this 2-series article we will take a deep dive into JavaScript’s prototypal nature – we will see how it works, and more importantly how we, as JavaScript developers can leverage it. We will take it a step further to see how we can develop our own hierarchies to model our code, allowing for better reuse.

Gone are the days when we, as developers could get away with one-off scripts to power our web pages. With the advent of rich, and highly interactive web applications, more and more “core” logic has shifted to the client making JavaScript a first class language within our code-base, and warranting such treatment. Developers are constantly looking to better model their code to reflect real world scenarios, in which inheritance plays an important role. JavaScript does provides you the ability to create rich and deep hierarchies, but does so in a fashion that is not immediately obvious to those coming from a language like Java. To better understand how we can use this valuable feature, we will need to dig past the surface, and examine how JavaScript uses objects, and functions in unison to make this happen.

I highly recommend that you play along with the code as you read this, but you will need a runtime. I suggest you use Google Chrome since it comes bundled with a JavaScript console. Just open up a new tab, right-click anywhere on the page, and select “Inspect Element”. A small window should pop open at the bottom of the page, with it’s own toolbar. The last item on the tool bar is called “Console” – Clicking that will bring you in to the JavaScript console. Another suggestion is to click the icon at the bottom-left of the JavaScript console (The tooltip says “Undock into a seperate window.”) – This detaches the Code Inspector from the main window and should give you much more real estate to play with^1 .

Ready? Let’s go find us some inheritance …

Objects

Fundamentally, JavaScript is object-oriented. To those familiar with JavaScript this should come as no surprise. JavaScript comes bundled with a few “global” objects, such as Array, Boolean, Date, String and Object. Instances of these are adorned with certain properties, and behaviors, such as [].length (which is the length of an array), or "javascript".toUpperCase() (which returns "JAVASCRIPT"). There is a subtle, yet important distinction here that I must highlight, and that will be relevant to our on-going discussion. [].length is merely looking up the value of a property in the array, much like you would look up a public variable on an object in Java. On the other hand, "javascript".toUpperCase() is invoking a method on the String instance. This pattern of invocation is referred to as the “Method Invocation Pattern”, in that you are invoking a function as a method of an object^2 .

There is another way to invoke a function, as shown in Listing 1

1
2
3
4
5

function sayHelloTo(name) {
    return "Hello " + name + "!";
}

console.log(sayHelloTo("Brendan")); // evaluates to "Hello Brendan!"

This is called the “Function Invocation” pattern because it seems that you are invoking a stand-alone function. This is not entirely correct – rather the function is attached to the “global” object, which in the case of your browser is the window object.

Creating your own objects

JavaScript allows you to create your own objects, and offers several ways to do so, each offering something subtly different. The easiest way to create an object is to use the literal syntax – {}. You can then attach properties and methods to this object, and you can look these properties up, or invoke these methods just like you would any JavaScript supplied object. Let’s take a look in Listing 2

1
2
3
4
5
6
7
8
9
10

 var myObj = {};

 myObj.name = "Some Object";
 myObj.sayHello = function(name) {
     return "Hello " + name + "!";
 };

 // try it out
 console.log(myObj.name); // evaluates to "Some Object"
 console.log(myObj.sayHello("Brendan")); // evaluates to "Hello Brendan!"

You can declare an object, and all the properties and methods in one fell swoop, as shown in Listing 3

1
2
3
4
5
6
7
8
9
10

var myObj = {
    name : "Some Object", // NOTE the : and the ',' at the end
    sayHello : function(name) {
        return "Hello " + name + "!";
    }
};

// try it out ... again
console.log(myObj.name); // evaluates to "Some Object"
console.log(myObj.sayHello("Brendan")); // evaluates to "Hello Brendan!"

Notice that instead of = signs we use :, and we separate the property definitions using commas as delimiters.

There is another way to define your own object, and that is to use the create method defined on Object. This method takes an argument, the meaning of which we will see in Part II of this series, but for now a null will suffice^3 . Let’s take a look (Listing 4)

1
2
3
4
5
6
7
8
9
10

var myObj = Object.create(null);

myObj.name = "Some Object";
myObj.sayHello = function(name) {
    return "Hello " + name + "!";
};

// try it out
console.log(myObj.name); // returns "Some Object"
console.log(myObj.sayHello("Brendan")); // returns "Hello Brendan!"

Now that we know how to create our own objects, it should be noted that even plain vanilla objects that you create, say with the literal {} syntax, have a few properties and functions magically defined on them. See Listing 5.

1
2
3
4
5
6
7
8
9
10
11
12

 var obj = {};

 console.log(obj.constructor); // returns function Object()
 console.log(obj.toString()); // returns [object Object]

 console.log(obj.nonExistentProperty); // returns undefined

 try {
     console.log(obj.nonExistingMethod());
 } catch (e) {
     console.log("Oops! " + e);
 }

As you can see, somehow our obj has a constructor property and a toString function. Just to prove they are the real deal, I invoked the nonExistingProperty property (which returns undefined) and invoked a nonExistingMethod that simply blows up! Where did the toString property come from? To answer that, add one more line to the script you ran in Listing 5, as shown in Listing 6

1

console.log(obj.__proto__);

Listing 6 – Seeing the __proto__ object

Within Chrome, the final line should show look like the screenshot I have captured in Figure 1 (Unfortunately there isn’t a way to show the properties of the object within Firefox – All you will see is Object { ... })

What just happened here, and what is that Object being shown in the console? Well, let’s take it a step at a time. obj.__proto__ is (in our example) equivalent to {}.__proto__. Essentially, we are asking our object for its __proto__ object. You see, every object in JavaScript has a “prototype” – This “prototype”, is just that – an object that acts as the template for any new object. This is where the “prototypal” in “prototypal inheritance” comes from – rather than having classes, we simply “clone” existing objects to allow for behavior reuse and inheritance.

This is very different from the class based inheritance many of us are used to in languages like Java. Rather than have two completely different animals – classes and objects like you do in Java (Yes, although classes are objects at runtime you have to admit they have special powers :D), within JavaScript you have only objects. Objects point to other objects and share behavior!

The relationship between our obj from Listing 5 and it’s __proto__ is illustrated in Figure 2

Notice that I have marked our obj’s __proto__ as Object.prototype. The reason for this will become clear after we finish the section on Functions, but from now on, I will refer to it as just that – Object.prototype.

Perhaps you see how method look up works in JavaScript now. When you asked for obj.toString(), JavaScript looked in our newly created object to see if it had a toString function. Needless to say, it didn’t find it, so then JavaScript follows the __proto__ pointer up to the Object which does have a toString! So JavaScript merely calls that function and returns. This is also the same reason why nonExistentProperty and nonExistentMethod both failed – neither our object nor it’s __proto__ have any such properties. Furthermore, Object.prototype does not have a __proto__ property – so this is the end of the line for the lookup chain.

Now that you know this, can you think of a way to write a custom toString method for our newly created obj object? It’s not that much different from Java. See Listing 7

1
2
3
4
5
6
7
8
9

 // declaring a new object because it's convenient
 // you can use the code in Listing GAN-5 and Listing GAN-6 if you like
 var obj = {};

 obj.toString = function() {
     return "I am a newly created object!";
 }

 console.log(obj.toString()); // evaluates to "I am a newly created object!"

What did we just do? We introduced a new property in our object, namely toString. Now when we ask our obj to evaluate toString JavaScript does not have to go far – it merely executes the first found implementation of the function, which happens to be the one owned by our newly created object. To see how this works, see Figure 3

Notice that I have merely stricken out the toString in Object.prototype and not removed it. By putting a newer definition in obj you don’t wipe out the one in Object, you merely shadow it. Furthermore, any new objects that are created without a toString implementation still use the one in Object.prototype. This is no different than inheritance you might be used to in Java-land. The top level (Java) Object class offers a default implementation of toString, and sub-classes can override it to suit their needs. The only difference being that in JavaScript there is no class construct – rather you deal with objects only.

The discussion so far works out fabulously if you need only one object to work with – you can add as many custom methods on to this object as you need and be on your merry way. But classes (like those in Java), and inheritance in general buys us a lot more than that – the ability to have a way to define certain functions and properties for a class of objects in one place, and have all “instances” automatically be adorned with certain behavior.

What if we wanted all of our objects to be able to greet other objects? If we were to put a sayHello method in Object.prototype, then any object created with it’s __proto__ property pointing to Object.prototype will automatically inherit that method. Let’s give it a whirl in Listing 8

1
2
3
4
5
6
7
8
9
10
11
12
13
14

 // declaring a new object because it's convenient
 // you can use the code in Listing GAN-5 if you like
 var obj = {};

 obj.__proto__.sayHello = function(name) {
     return "Hello " + name + "!";
 }

 console.log(obj.sayHello("Brendan")); // evaluates to "Hello Brendan!"

 // create another object
 var anotherObj = {};

console.log(anotherObj.sayHello("Douglas")); // evaluates to "Hello Douglas!"

When we say obj.__proto__ we are getting a reference to the Object.prototype object. We then tack on sayHello on to it, and then create anotherObject (which automatically inherits from Object.prototype). This is illustrated in Figure 4

Problem solved? Not quite. Most of us would be frowning right about now. By introducing the sayHello in the Object.prototype every object has the ability to speak! This includes the objects that JavaScript ships with. Try [].sayHello("John") in your console. Needless to say, this is a sledge-hammer approach to inheritance. No Java programmer worth his salt would (if they could) put this method in Object.

So what we need is a way to introduce newly created objects with their own “prototype” object – one that adorns them with specific behaviors that are applicable to any object of that class or genre. How do we do that?

That is the question we are here to answer. Before we go there, we need to talk at about functions in JavaScript^4 .

Functions

JavaScript is a functional programming language, in that functions are first-class citizens. This is a departure from languages like Java where functions, or rather methods are underlings to the objects to which they belong. What this means is that functions are like any other datatype in JavaScript – Just as you would assign a String to a variable or return a Number from a function (or a method), you can do the same with functions. You can assign a function to a variable (and you saw an example of this in Listing 2 where we assigned sayHello to a function) and you can pass functions as arguments to other functions. You can even have functions create other functions a.k.a higher-order functions. Let’s explore some of these concepts really quickly in Listing 9

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// extremely contrived example but math operators in
// JS are baked into the language. This is just a simple
// wrapper
// This is NOT idiomatic.
function add(a, b) {
    return a + b;
}

var somePointerToAdd = add; // have a variable point to the 'add' function
// You can invoke add in multiple ways
console.log(add(2, 3)); // returns 5
console.log(somePointerToAdd(2, 3)); // returns 5
console.log(somePointerToAdd == add); // prove they are the same - returns true
// This function creates an "incrementor" function and returns.
// Given an arg 'n' it returns a NEW function
// that takes just one argument and upon invocation returns 'add(n, arg)'
function incrementBy(n) {
    return function(arg) { return add(n, arg) };
}

// essentially returns function(arg) { return add(3, arg); }
var incrementor = incrementBy(3);
// invoke function(arg) { return add(3, arg); } giving it 5 as an arg, returns 8
console.log(incrementor(5));

Note that incrementor is a pointer to the newly created function that gets returned by incrementBy(3). This is no different than saying var x = "Brendan".

This is a powerful construct, and makes JavaScript an incredibly powerful language, but as is always the case with JavaScript, there is more to it than meets the eye. JavaScript functions, are in fact, full blown objects in and of themselves! If you were to glance at the JavaScript documentation you will see that there is a ‘Function’ object, it succinctly says

Every function in JavaScript is actually a Function object.

Our earlier discussion about objects, properties, and methods applies to functions as well. That is, functions can have properties and methods assigned to them! Whenever you declare a new function in JavaScript, a new Function object is created, and much like other objects (like we saw in Listing 5) are blessed auto-magically with a few properties, of which, constructor and prototype being the ones relevant to our discussion at hand. You can get a handle to the function object simply by using it’s name, like Person. (I noted in 2 that you could do "javascript".toUpperCase, without the parentheses – that is essentially giving you back a handle to the toUpperCase function). See Listing 10^5

1
2
3
4
5
6

 function Person(name) {
     // ignore the argument for this listing
 }

 console.log(Person.prototype); // evaluates to Person { }
 console.log(typeof Person.prototype); // evaluates to "object"

Notice that the prototype property evaluates to an object, which happens to be just another plain vanilla JavaScript object. See Figure 5 for a (simplistic) illustration on how this works.

The object on the left is the Person function object, and the object to the right is it’s “prototype”, which happens to be a plain JavaScript object. Two things of note here – Functions get a special “prototype” property (different from the __proto__ property we saw earlier), and the functions prototype object (which happens to be a simple JavaScript object) gets a __proto__ property just like we saw in the earlier section. The prototype object’s constructor property points back to the function object itself. The way you refer to a function’s (in this case Person) prototype is just like you would any other property – <name_of_object>.<name_of_property> – so to reference Person’s prototype we say Person.prototype.

If this looks familiar, it’s because it is. Earlier (in Figure 2) I marked our obj’s __proto__ as Object.prototype! Looking at Listing 10 what can we infer? Simply put, there is a function object called Object, in that there is a function declared with the name Object (like so function Object() { ... }), for which JavaScript creates a (Function) object, and this object points to another (plain vanilla JavaScript) object that happens to be it’s “prototype”. See Figure 6 to get an idea of how this lays itself out.

To summarize, functions in JavaScript are just objects, albeit a little special because they all have a prototype property. This prototype property is just another object, which like any other object that you create, is part of an inheritance chain with Object.prototype at the end.

Now that we know all this, how can we use this to properly adorn our “person” objects with a predefined set of behaviors? Well, we still have one more hurdle to surmount before we get there, but unfortunately, we have reached the end of our journey for this installment. In part 2, we will first see how functions can be used as constructors, and use this to build our own inheritance hierarchies in JavaScript.

A minor digression

So far in this article, I have used the word “object”, and “instance”. This can be a contentious issue in JavaScript’s terminology due to the fact that JavaScript does not have the traditional notion of a “class” – so what exactly constitutes an “instance”? Well traditionally, in languages like Java, an instance is an object. But in JavaScript, as we have noted, constructs like the function Object, and our own Person (which as we will see in our next installment are the conduits to creating “instances”) are also objects.

One way to define an “instance” is like so – “instances” are created when we use the new keyword along-with a function name. Consider var myString = new String("Douglas") – in this case, myString is an “instance” of String. We should note that sometimes this is not so obvious. IN Listing 2 we used the literal syntax ({}) for creating a new object – Under the covers this (roughly) translates to new Object() – so once again, we have created an “instance” of Object. Other examples include [1, 2, 3] (which happens to be an Array) instance, and /+d/ which is an instance of RegExp.

The thing to take away here is that in a language like JavaScript, the distinction between “instances” and “objects” boils down to being borderline academic. As long as you understand how to use objects, and (in Part 2) how functions can be used as “instance factories”, in my opinion there is no reason to fret over the terminology.

Conclusion

JavaScript is inherently an object-oriented language. More so than many languages that we may have encountered, in that in JavaScript functions are also objects, albeit with a difference. Objects are adorned with properties, including a magical property called __proto__, which allows the object to participate in an inheritance, and look-up chain. Functions, on the other hand, are a tad special, and have an additional property called prototype and we will see how we can use this to build our own hierarchies in Part 2.

1. You can also use FireFox along with Firebug. Once you have that installed, create a new HTML file with the contents <!DOCTYPE html><title>On Protoypal Inheritance</title> and save it anywhere on your computer. Then open the newly created file in Firefox, right-click anywhere on the page, and select “Inspect Element with Firebug”. This too has a menu bar of it’s own that has a “Console” option. Clicking that will bring you into the JavaScript console. If you are on a Mac, Safari (Version 5.1.3) also has a console similar to that of Chrome’s.

2. You could even do "javascript".toUpperCase (note that there are no parenthesis following the method name) but this does something very different, and which hopefully will become more apparent as we go forward.

3. You can create the object, along with certain properties and methods in one fell swoop like we did in Listing 2 but I left that out for two reasons – It does not help our discussion here, and the syntax can be a tad confusing. For details see this link.

4. I realize that this section may have left you with more questions than answers, but I promise that it will all become clear soon.

5. I realize that the function has a name starting with a capital “P” vs. a lowercase as is usually the case. I can tell you that there’s a good reason :)