JavaScript Inheritance: A Form of Composition

Lectures 53 through 56 of JavaScript: Understanding the Weird Parts discuss more about the creation and manipulation of objects under the hood. I’d seen different aspects of this material previously, which gave me a different take on how to build up objects using prototype inheritance, but these lectures took the ideas apart and put them together in a whole new way.

Let me start by describing what I’d understood previously, and how I did so in terms of OOP formations I’ve seen in previous lives as a Pascal and then C++ programmer for many, many years.

Let’s start by looking at an object I build up using prototypes in the Discrete-Event Simulation project, namely the base entity object that represents items that are moved through the model. I described how I moved all of the member functions to be outside prototypes so the instantiated objects would be smaller here but I don’t think I ever displayed the code, so here it is. The original internal functions are present but commented out so you can see their original form, and the prototype copies of those functions are included below the closure definition, but attached to the closure.

My conception of what’s going on under the hood may not be correct, but I’m visualizing that the JavaScript engine is storing prototypes of each method separately in memory and instantiating objects that include links to the methods instead of complete copies of the methods for each instantiated object. I was thinking of this as being similar to a virtual method table in a more traditional language, where the instantiated object includes memory space for the data members and a single pointer to an entry in the VMT that describes what methods are accessible to that object in that object hierarchy. The setups would not be analogous but the ideas would be similar. The point of the exercise in JavaScript, at least for my purposes, was to reduce the size of the instantiated objects because you don’t want them to carry the burden of huge amounts of code if large numbers of them are going to be created. The data members (properties) have to be unique for each instantiation but the function definitions can be shared.

Various instructions around the web gave me the idea, that prototype inheritance can be used to create different object configurations be defining an initial object with a given set of prototype functions, as I’ve done with EntityPassive, and then add — and remove — prototype functions and members to create the new forms that are desired. This is different than what I’m used to, where object hierarchies can only be defined so the descendant objects are necessarily larger than the parent objects on which they are based. The JavaScript method seems more flexible.

All this said, that was just my conception, I never experimented with actual code to see just how this could work. I envisioned it as being just a hair clunky, but there’s some possibility that it doesn’t work like this at all.

That brings us to the present subject, which is a different description of how those methods work. I can see the similarities to my conception but a) the material in the lectures is very clear and b) the demonstrations show that what is described actually works.

The presenter provided a lot of background concepts to set everything up, then walks through the implementation of the extend function in the Underscore.js library. It uses the ideas of reflection and composition to parse other object definitions to determine what properties they contain (data and function members) and adds them to the object of interest. The parsing process is reflection and the addition process is a form of composition.

Here’s the relevant code from Underscore.js:

Here’s the class example of how this is invoked (see line 36):

In the end I’m thinking that my conception was pretty well on target. The composition-by-addition demonstrated here works the way I envisioned, and objects can as easily be modified by removing elements. That said, defining things this way vs. using prototype definitions as I did above creates objects that have different payloads under the hood. This is something that must be understood by the practitioner. I look forward to seeing what, if anything, the presenter has to say on the subject.

This entry was posted in Software and tagged , , , , , , . Bookmark the permalink.

Leave a Reply