Overview of SOM
From AIXpert August 95
In SOM, classes are objects whose classes are called metaclasses. A class differs from an ordinary object, because a class has (in its instance data) an instance method table defining the methods to which instances of the class respond. During the initialization of a class object, a method is invoked on it, informing the class of its parents. This allows the class to build an initial instance method table. After this is done, other methods are invoked on the class to override inherited methods or to add new instance methods.
When diagramming class hierarchies, this article shows metaclasses drawn with three concentric circles, ordinary classes (classes that are not metaclasses) drawn with two concentric circles, and ordinary objects (objects that are not classes) drawn with a single circle. The initial state of an example SOM program is depicted in Figure A. There are four objects: SOMObject (class), SOMClass (a metaclass), Dog (an ordinary class), and Rover (an ordinary object).
There are two relationships among objects that must be understood. First, there is the instance of relation between objects and classes depicted by the dashed arrow from an object to its class. When convenient, the inverse relation-class of-is also used. SOMObject is an instance of SOMClass, and SOMClass is the class of itself. An object's class is important because an object responds only to the methods that are supported by its class-the methods that the class introduces or inherits.
Second, there is a relationship between classes called the subclass of relation, which is depicted by the solid arrow from a class to each of its parents. SOMClass is a subclass of SOMObject. SOMObject has no parents.
SOMObject introduces the methods to which all SOM objects respond. In particular, SOMObject introduces the somDispatch method, which provides a single general dynamic dispatch mechanism for executing method calls on objects. Furthermore, a class can arrange its instance method table so that all method calls are routed through somDispatch. As a result, it is simple for SOM metaclass programmers to arrange for completely arbitrary processing in connection with method invocations on SOM objects.
As a subclass of SOMObject, SOMClass is an object, but it also introduces the methods to which all classes respond. For example, SOMClass introduces the somNew method, which creates instances of a class. Also, the methods responsible for creating and modifying instance method tables are introduced. All metaclasses in SOM are ultimately derived from SOMClass. (Similar arrangements of classes are also used in CLOS7, ObjVlisp2, Dylan1, and Proteus12.) The SOM API allows new abstractions to be created by programming metaclasses. In more general terms this has been called a metaobject protocol7,8 or computational reflection9. The strength of this general approach is that new abstractions can be created after the object model is implemented. That is, the Before/After Metaclasses are not part of the SOM kernel, but they are part of a framework for programming metaclasses (see Reference 3 for more information) that is built with the SOM API. By providing a metaobject protocol, we were able to add a new abstraction to SOM.
Interfaces to SOM objects are described using IDL, an object interface definition language defined by the Common Object Request Broker Architecture (CORBA10) standard of the Object Management Group (OMG). SOM IDL is a CORBA-compliant version of IDL that allows SOM class descriptions to be supplied in addition to object interface definitions. (The interface to a class is described by the IDL alone. SOM IDL allows additional information about the implementation to be added.) The SOMObjects Toolkit has tools called emitters that translate SOM IDL into language-specific bindings for the corresponding classes of SOM objects. For example, to C and C++ programmers this means that emitters produce header files for both the users and the implementer of the class.
The following example shows the basic structure of an IDL definition for an object interface named Dog.
interface Dog : SOMObject {
// method and attribute declarations
//here
#ifdef __SOMIDL__
implementation
{
metaclass = SOMClass;
// instance variable declarations
// here
};
#endif
};
At the same time, it is a SOM IDL description of a class Dog that supports this interface. The #ifdef and #endif - part of the CORBA IDL language - are used to hide the SOM class implementation section from non-SOM IDL compilers.
In this example, the interface Dog inherits from the SOMObject interface, and at the same time, the class Dog is declared to be a subclass of SOMObject. CORBA and SOM support multiple inheritance; additional parents of Dog can be listed alongside SOMObject in a comma-separated list. The actual methods and instance variables of Dog are not relevant to the current discussion.
As illustrated here, the implementation section can explicitly indicate a metaclass to be associated with the class of objects that supports the interface being defined. This association is not necessarily direct. For reasons described in this article, the actual class of the class described by any given SOM IDL is, in general, a subclass of the indicated metaclass.
Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation
