To re-emphasize: All code written prior to SOMobjects Release 2.1 using documented guidelines for the earlier initialization approach based on the somInit method (as well as all existing class binaries) continues to be fully supported and useful.
Prior to SOMobjects 2.1, initialization was done with initializer methods that would simply "chain" parent-method calls upward, thereby allowing the execution of initializer method procedures contributed by all ancestors of an object's class. This chaining of initializer calls was not supported in any special way by the SOM API. Parent-method calls are simply one of the possible idioms available to users of OOP in SOM, easily available to a SOM class designer as a result of the support provided by the SOMobjects Toolkit emitters for parent-method calls.
So, SOM did not constrain initialization to be done in any particular way or require the use of any particular ordering of the method procedures of ancestor classes. But, SOM did provide an overall framework that class designers could easily utilize in order to implement default initialization of SOM objects. This framework is provided by the somInit object-initializatio method introduced by the SOMobject class and supported by the SOM Toolkit emitters. The emitters create an implementation template file with stub procedures for overridden methods that automatically chain parent-method calls upward through parent classes. Many of the class methods that perform object creation called somInit automatically.
Note: These will now call somDefaultInit, which in turn calls somInit for legacy code, as described in the previous topic.
Because it takes no arguments, somInit best served the purpose of a default initializer. SOM programmers also had the option of introducing additional "non-default" initialization methods that took arguments. In addition, by using metaclasses, they could introduce new class methods as object constructors that first create an object (generally using somNewNoInit.) and then invoke some non-default initializer on the new object.
For a number of reasons, the somInit framework has been augmented by recognizing initializers special kind of method in SOMobjects. One advantage of this approach is that special metaclasses are no longer required for defining constructors that take arguments. Instead, because the init modifier identifies initializers, usage-binding emitters can now provide these constructors. This results in simpler designs and more efficient programs.
Although somDefaultInit replaces somInit as the no-argument initializer used for SOM objects, all previous use of somInit is still supported by the SOMobjects Developers Toolkit on AIX, OS/2 and 16-bit Windows. You may continue to use somInit on these systems if you like, although this is somewhat less efficient than using somDefaultInit.
However, you cannot use both methods. In particular, if a class overrides both somDefaultInit and somInit, its somInit code will never be executed. It is recommended that you always override somDefaultInit for object initialization. For one thing, it is likely that when SOMobjects is ported to new systems, somInit (and somUninit) may not be supported on those systems. Thus, code written using these (obsolete) methods will be less portable.