Initializer methods

As noted above, in the SOMobjects Toolkit each ancestor of an object contributes to the initialization of that object. Initialization of an object involves a chain of ancestor-method calls that, by default, are automatically determined by the SOM Compiler emitters. The SOMobjects framework for initialization of objects is based on the following approach:

• SOMobjects recognizes initializers as a special kind of method, and supports a special mechanism for ordering the execution of ancestor-initializer method procedures. The SOMObject class introduces an initializer method, somDefaultInit that uses this execution mechanism.

• The SOM Compiler's emitters provide special support for methods that are declared as initializers in the .idl file. To supplement the somDefaultInit method, SOM class designers can also declare additional initializers in their own classes.

Two SOM IDL modifiers are provided for declaring initializer methods and controlling their execution, init and directinitclasses:

• The init modifier is required in order to designate a given method is a initializer; that is, to indicate that the method both uses and supports the object-initialization protocol described here.

• The directinitclasses modifier can be used to control the order of execution of initializer method procedures provided by the different ancestors of the class of an object.

• For full definitions of init and directinitclasses, see the topic "Modifier statements" in Chapter 4,"SOM IDL and the SOM Compiler."

Every SOM class has a list that defines (in sequential order) the ancestor classes whose initializer method procedures the class should invoke. If a class's IDL does not specify an explicit directinitclasses modifier, the default for this list is simply the class's parents - in left-to-right order.

Using the directinitclasses list and the actual run-time class hierarchy above itself, each class inherits from SOMClass the ability to create a data structure of type somInitCtrl. This structure is used to control the execution of initializers. Moreover, it represents a particular visit-ordering that reaches each class in the transitive closure of directinitclasses exactly once. To initialize a given object, this visit-ordering occurs as follows: While recursively visiting each ancestor class whose initializer method procedure should be run, SOMobjects first runs the initializer method procedures of all of that class's directinitclasses if they have not already been run by another class's initializers, with ancestor classes always taken in left-to-right order.

The code that deals with the somInitCtrl data structure is generated automatically within the implementation bindings for a class, and need not concern a class implementor.

When an instance of a given class (or some descendant class) is initialized, only one of the given class's initializers will be executed, and this will happen exactly once (under control of the ordering determined by the class of the object being initialized).

The somInitCtrl structure solves a problem originally created by the add ition of multiple inheritance to SOMobjects 2.0. With multiple inheritance, any class can appear at the top of a multiple inheritance diamond. Previously, whenever this happened, the class could easily receive multiple initialization calls. In the current version of the SOMobjects Toolkit, however, the somInitCtrl structure prevents this from happening.