April 2002

Multiple Instantiation (Mixins)

Overview

Multiple Instantiation (MI) reduces the necessary complexity of the class hierarchy. By allowing instantiation from a set of orthogonal class definitions, a large variety of behaviors can be generated from a relatively small number of classes. This orthogonal nature of the classes is assumed for all further discussion.

MI can be done when class definitions overlap. This is handled by an appropriate multimethod protocol.

Example

To prove that we are talking about something useful, we have an example:

Employee
Salary
Benefit
Options

Customer
Total
Sales

We are not concerned about where these objects are placed in the class hierarchy, but with the fact that neither inherits from the other. Any person can be either an employee, a customer, neither or both. Instead of creating four classes to represent the four combinations, we allow MI to keep the class hierarchy simple.

Possible Implementations

MI is not difficult to implement naively, but an efficient implementation is more difficult. Despite our efforts, we should expect equal or lesser performance from a system implementing MI because it is considering more possible message handlers then in the single instantiation case.

Review of Single Instantiation

When a message is received by an object, it must be resolved to a function call. In the case where there is only one then the resolution is easy. When a handler overrides another then the object's type must be considered. There must be a map that takes object type, message type and resolves the function that must be executed.

It is easy to keep track of what class an object belongs by including it as part of the object description. Many languages do this implicitly; adding an extra word to the object struct containing a reference to the class. Incoming messages are routed via a lookup table based on class.

Implementation of Multiple Instantiation

The primary problem with MI is not the resolution, but the how to handle the large number of classes that a single object can be an instance of. Simply adding a list of classes to each object's descriptive structure is bloated and slow to step through. Some combinations of class instances are bound to happen more than once, therefore, if every object is to have an instantiation list there would be a duplication of effort. Instead, we can keep this instantiation list as a separate, shared, object.

Here is a diagram of the transformation used by the language backend to implement MI. Note the shared object (A B) is a virtual class.

This virtual class that inherits from the parent classes; the instantiation list is now an inheritance list. Any object that is an instance of these same parent classes will automatically be an instance of this virtual class. These virtual classes are called sigma classes in the DBOS.

Apr 30 2002: Added diagram and improved implementation description