From EDM2
Jump to: navigation, search

This method initializes instance variables and attributes in a newly created object. Replaces somInit as the preferred method for default object initialization. For performance reasons, it is recommended that somDefaultInit always be overridden by classes.

Original Class 


void somDefaultInit (SOMObject receiver, somInitCtrl ctrl)


receiver (SOMObject)
A pointer to an object of type SOMObject.
ctrl (somInitCtrl)
A pointer to a somInitCtrl data structure. SOMobjects uses this data structure to control the initialization of the ancestor classes, thereby ensuring that no ancestor class receives multiple initialization calls. A pointer to a class that is an ancestor of the actual class of the receiver.

Return Code

rc (void)


Every SOM class is expected to support a set of initializer methods. This set will always include somDefaultInit, whether or not the class explicitly overrides somDefaultInit. All other initializer methods for a class must be explicitly introduced by the class.

The purpose of an initializer method supported by a class is first to invoke initializer methods of ancestor classes (those ancestors that are the class's directinitclasses) and then to place the instance variables and attributes introduced by the class into some consistent state by loading them with appropriate values. The result is that, when an object is initialized, each class that contributes to its implementation will run some initializer method. The somDefaultInit method may or may not be among the initializers used to initialize a given object, but it is always available for this purpose.

Thus, the somDefaultInit method may be invoked on a newly created object to initialize its instance variables and attributes. The somDefaultInit method is more efficient than somInit (the method it replaces), and it also prevents multiple initializer calls to ancestor classes. The somInit method is now considered obsolete when writing new code, although somInit is still supported.

To override somDefaultInit, the implementation section of the class's .idl file should include somDefaultInit with the override and init modifiers specified. (The init modifier signifies that the method is an initializer method.) No additional coding is required for the resulting somDefaultInit stub procedure in the implementation template file, unless the class implementor wishes to customize object initialization in some way.

If the .idl file does not explicitly override somDefaultInit, then by default a generic method procedure for somDefaultInit will be provided by the SOMobjects Toolkit. If invoked, this generic method procedure first invokes somDefaultInit on the appropriate ancestor classes, and then (for consistency with earlier versions of SOMobjects) calls any somInit code that may have been provided by the class (if somInit was overridden). Because the generic procedure for somDefaultInit is less efficient than the stub procedure that is provided when somDefaultInit is overridden, it is recommended that the .idl file always override somDefaultInit.

Note: It is not appropriate to override both somDefaultInit and somInit. If this is done, the somInit code will not be executed. The best way to convert an old class that overrides somInit to use of the more efficient somDefaultInit (if this is desired) is as follows: (1) Replace the somInit override in the class's .idl file with an override for somDefaultInit, (2) run the implementation template emitter to produce a stub procedure for somDefaultInit, and then (3) simply call the class's somInit procedure directly (not using a method invocation) from the somDefaultInit method procedure.

As mentioned above, the object#initialization framework supported by SOMobjects allows a class to support additional initializer methods besides somDefaultInit. These additional initializers will typically include special#purpose arguments, so that objects of the class can be initialized with special capabilities or characteristics. For each new initializer method, the implementation section must include the method name with the init modifier. Also, the directinitclasses modifier can be used if, for some reason, the class implementor wants to control the order in which ancestor initializers are executed.

Note: It is recommended that the method name for an initializer method include the class name as a prefix. A newly defined initializer method will include an implicit Environment argument if the class does not use a callstyle=oidl modifier. There may be constraints associated with modification of the procedure stubs for initializers.

Example Code

#include <Animal.idl>

interface Dog : Animal
    implementation {
        releaseorder: ;
            somDefaultInit: override, init;

Original Class