JavaScript Inher . . .

© 2011, Martin Rinehart

Damn. I can't even bring myself to spell it out. Let's change worlds—go someplace where "inheritance" makes sense.

Inheritance was what you thought you might have coming from your rich Uncle Wilbur. Good guy. Told funny stories and spoiled you rotten. Built the biggest widget company in the western world before he sold to Amalgamated. Too bad that Vegas dancer got her hooks into him so deep. Looks like that inheritance is never going to happen. Sorry.

But this is about software. About JavaScript. No class in JavaScript was ever going to inherit from Uncle Wilbur or anyone else. Now I'm going to say it as close as I can come: JavaScript features "prototypal inheritance" in lieu of the "class-based inheritance" featured in languages such as C++, Java and Ruby.

There. I've said it. And I'm not going to say it again.

Forget Inher . . .

There never was such a thing as "inher . . ." in software, class-based or otherwise. The word was commonly used to speak about the way one class could extend another. This article is just a fast, get-the-terminology-right, frontend for the next three. You could say the next three articles "extend" this one. It would be just plain stupid to say that the others inherit from this article. They inherit nothing. This article has no fortune, no widget company, no shares of Amalgamated and it won't even draw a second glance from any Las Vegas dancer.

By the by, if you're reading this beside the pool in Vegas and one of those dancers passes by and asks, try, "It's about how to build the next FaceBook." That may work better than, "It's about extending classes in JavaScript."

And before we get on to extending classes, lets bury two other words that are even dumber.

And Forget Su . . .

Unless this is your introduction to "inher . . ." in object-oriented programming, you have probably seen the words "superclass" and "subclass." From my own experience I can tell you how much they get in the way of learning some simple OOP concepts. I was getting no where with OOP until I learned this simple truth: if A is the superclass of B, B is a superset of A. If B is a subclass of A, A is a subset of B.

Right. The terminology is exactly backwards. You start with one class, like A. Then you add some stuff to create a new, extended class, B. B has everything that A had, plus some more. Bjarne Stroustrup (who created C++) was the first to call the old terminology stupid. (I think he was polite. He said it was misleading or some such. Let's just call it stupid.)

We are going to dive into a world where class B adds stuff to class A. B will be a superset of A. If you prefer, A will be a subset of B. I tell you the following so you will be warned; so you will possibly be able to make sense of the really stupid terminology; so you will be able to answer a question from some yo-yo who's dumber than a post but is interviewing you for a software job. A "superclass" is the smaller, original class that we needed to extend. A "subclass" is the larger, superset class that extends the smaller original class. And from now on I will only use "su" to start words "superset" and "subset" and they will mean exactly what you thought: a "superset" of a smaller class is the one that contains everything in the smaller class, plus some more stuff, too.

Do I hear a question? OK, I see you've only recently escaped from a math class. The question is, is A a superset of B if it is exactly equal to B. The answer is, "I don't care!" You could have one class that "extends" another by adding exactly nothing, but that would be a complete waste of your time. We're talking writing code. You want to build the next FaceBook? You've not got time for theoretical questions. You've got stuff to build. Let's get on with it.

Series Overview

There are three more articles in this series:

  1. Extending Classes in Class-Based OOP
  2. Extending JavaScript Data Properties
  3. Extending JavaScript Methods

The first article tells you why you want to do this extending thing. It's critically important in class-based OOP. It's still important (though you can live without it) in prototypal OOP. It's one of the things you want to know if you really want to get good at JavaScript.

The second article tells you the right way to extend a base class's data properties. At least 99 percent of what you read about "inher . . ." in JavaScript is completely wrong on this subject. Half of that is wrong because the authors didn't understand what needed to be done. Doing it is simple.

The third puts the frosting on the cake. You'll see the tradeoffs and the way one class can take advantage of methods from another class. You'll have a set of tools that will make your class-based friends green with envy. Let 'em drool!

Feedback: MartinRinehart at gmail dot com

# # #