To employ laziness.

In JS any object can have a special link to another such that if JS cannot find a key-value pair in the former, it also looks in the latter before failing.

Looking up a hierarchy is the essence of inheritance and the special link that forms the hierarchy between two standard objects is the defining feature of prototypical inheritance. JS, as is now obvious espouses prototypical inheritance.

In prototypical inheritance, the object that carries the special link is called the instance and the object to which it links to is called its prototype.

Note: As this topic is one of the rat’s nest that JS is notorious for and also a very puzzling juncture where most beginners go home, I’m going to go ahead and do something drastic to alleviate some of the pain usually encountered while tackling this topic. Sure there’s no gain without pain but trust me, there are worthier causes. With that, I’m going to pretend that the ECMA standard, IE and Opera doesn’t exist! We sure will bring them back into the fold. But that’s only much later. But to make painless progress in this front, ignore them. For now.

So by now you should be running interpreters provided by the house of Mozilla and the family of KHTML (Chromium, Webkit, et al).

Let’s consider that for our program, we have lots of objects similar to these two.

var flub = { color : "green", size : 20, speed : 40, weapon : {name : 'slime', ammo : 100} }, blob = { color : "red", size : 20, speed : 30, weapon : {name : 'slime', ammo : 100} };

We immediately see that these objects have common key-value pairs (properties). So to save us some typing (more than anything else), we make an object having the common properties and set it as the prototype of all the objects that needs these properties.

As a consequence, we get for free the ability to centrally tweak the common properties of all the instances of that prototype, also, in the process of naming the prototype object, we may attain a deeper insight into our program. After all, prototypes (as defined by the dictionary) are a convenient forgetfulness (abstraction) that represents similar objects.

So here’s how we go about doing that.



Create the object that will act as the prototype.

var thingy = { size : 20, weapon : {name : 'slime', ammo : 100} }

Create the objects that will act as the instances.

var flub = { color : "green", speed : 40 }, blob = { color : "red", speed : 30 };

This doesn’t look like much of a saving. But you’re only saying that because we’re only dealing with a few objects. You’ll quickly change your opinion (as I’m sure you will) when dealing with hundreds of similar objects in real programs.

Okay, you say. We have some objects.. now what?

Enter __proto__ the non-standard unreliable hero.

See, __proto__ is a modifiable key that objects created by the implementations mentioned previously provide. Assigning to the __proto__ property of an object causes it to inherit (be the instance of) the assigned object (prototype). Thus.

flub.__proto__ = blob.__proto__ = thingy;

You should from the previous post know that = operator is right associative and that its value is the assigned object leading to a cascade that sets both flub.__proto__ and blob.__proto__ to refer to thingy .

Accessing a non-existent value from an instance will cause JS to follow the hidden link ( __proto__ ) up the hierarchy looking for what we asked it to find.

So… You may visualize what we did as follows.

Looks pretty complicated but that’s only because we’re looking at the all at once exploded view. Imagine the exploded view of your mobile phone (using which is of-course second nature) for contrast.

When actually using objects, we should be at ease as using a mobile phone. Because with practice and with programs having numerous objects, we won’t be thinking about it all at once. We’d be employing the hierarchical nature of our thought process to forget most of the detail. A session on the REPL should help cement some of these ideas.

Refer the diagram above, and trace JS’s activity through it.

>> flub.color //As expected. >green >> blob.color //Same >red >> flub.size //JS looks up the prototype chain to thingy and gets size from thingy. >20 >> flub.weapon.name //We can keep qualifying as needed and JS follows along. >slime >> blob.weapon.name //Same as above. But from a different object. >slime >> blob.weapon = {name: 'laser', ammo: 40}; //Mew weapon object assigned to blob >[object Object] >> thingy.weapon.name //But not to the prototype (thingy) >slime >> blob.weapon.name //Blob has its own weapon. >laser >> blob.__proto__.weapon.name //Explicitly asking JS to follow __proto__. >slime >> flub.weapon.name //Flub has no weapon. JS follows the proto chain. >slime >> thingy.size = 100; //Assigning to the prototype object directly. >100 >> flub.size //Leads to dynamic changes in its instances. >100 >> blob.size //Same as above. >100 >> flub.__proto__.size = 40; //Assigning to prototype via the __proto__ reference. >40 >> blob.size //As expected. >40

At its core, this is all there is to JS’s flavor of prototypal inheritance. The rest is all JS’s self important posturing. The ECMA standard hides the special link ( __proto__ ) and goes on in a round about way how to achieve more or less the same thing.

But we cannot wrangle JS like this in polite company and we sure should learn to be diplomatic and standard compliant with JS. But that’s for later. For now, we can rest assured at having the upper hand.

Activities.

More REPLing.

Try chaining objects using __proto__ .

Share this: Twitter

Facebook

Like this: Like Loading...

Tags: inheritance, JavaScript, object oriented, objects, prototype, __proto__