Professional JavaScript

Inheritance via Object Masquerading

If you want to create a derived object instance, and you don't want the risk that it might be changed under you, then this is the approach to use. Here is the example from the last section slightly modified:

In addition to three new lines, the prototype assignment line at the end is missing as well. There are no prototype chains in this example at all. Instead, when the object is constructed, a temporary property is made for the base class' constructor, and that constructor is called as though it were a method of that object. All the properties set by the Polygon constructor are set directly in the Rectangle object. This has to be done first in the Rectangle constructor, because if it were last, some of the properties set by the derived object might be overridden by the base class constructor – back to front. In fact, when the base class constructor is called, it thinks that it is operating on an object whose destiny is to be of that base class type.

When the temp() method is called in the above example, you can supply arguments to it much like any method – of course those arguments should make sense when the Polygon() constructor gets them.

'ECMAScript 2' plans to replace this awkward three-statement approach with new, purpose-built functions requiring only a single statement:

According to the draft of 'ECMAScript 2', the two functions differ only in how arguments are supplied to them. At the time of writing, these functions are too new to be relied upon much. Nevertheless, you can find them in Netscape browsers, versions 4.06 and greater and Internet Explorer 5.0, or where JScript 5.0 is installed.

The benefits of this second inheritance approach, regardless of what syntax you use are:

• The object shares no information with other objects after it is created and can be considered independent
• The "type" of the object is frozen at create time – no changes to the base class afterwards will affect it.
• Arguments can be passed to the base class constructor.
• Multiple inheritance is possible (see below).

• If the base class inherits from an even-more-base class (e.g. Polygon might derive from Shape), then the derived class (Rectangle) won't benefit from that third class since it was never put in the prototype chain (for Rectangle objects).

If this line is added back at the very end, then the deeper-level inheritance problems go away.

However, since all type properties of the base class were set directly into the derived class, all of the base class properties are now overridden – changes to the base class won't necessarily filter through to the derived class. So it is a mistake to think that doing this gives you all the benefits that were to be had in the first approach to inheritance.

Finally, this system supports multiple inheritance. The multiple inheritance it supports is only one level deep, however. All that is required is to repeat the trick at the core of this technique more than once:

Further Reading on Prototype Inheritance

These references are invaluable sources of information on prototype inheritance if you want to get your hands really dirty. The author acknowledges them as contributing to the information presented in this chapter.

At Sun Microsystems, http://www.sunlabs.com/research/self/papers/papers.html contains a number of articles about the Self language. Self may be considered the precursor to the JavaScript language in many respects.

At Netscape, http://developer1.netscape.com:80/docs/manuals/communicator/jsobj/contents.htm has a comparison of the inheritance support available in JavaScript compared with Java.