IBM SOM: external object system with support for inheritance

I would like to share my find: IBM SOM. According to Wikipedia , there was once Microsoft with COM, and IBM was with SOM. On Windows and OS / 2, respectively. And they had the means of interconnection for them: DCOM and - what do you think? - right, DSOM. Such is the idyll, which may give the impression that they are twins. Only here in SOM there was inheritance, but in COM it was not, and in journalistic articles, which are referenced from Wikipedia , this is all about it.


But this is only the beginning of the journey to the rabbit hole.

There is documentation on SOM, there are reviews, but I would call 4 articles by Scott H. Danforth and Ira R. Forman (Ira is a male Hebrew name) as such documents according to which you can make an impression:
')
www.edm2.com/index.php/Scott_H._Danforth

• Binary Compatibility Releases to Releases SOM Article: Ira R. Forman, Michael H. Conner, Scott H. Danforth and Larry K. Raper (IBM's System Object Model) (1995)
• Reflections on Metaclass Programming in SOM by Ira R. Forman, Scott H. Danforth (1994)
• Inheritance of Metaclass Constraints in SOM by Ira R. Forman, Scott H. Danforth (1994)
• Composition of Before / After Metaclasses in SOM by Ira R. Forman, Scott H. Danforth, Hari Madduri (1994)

The most delicious moments:

RRBC:

This can be stated as:
Only application alteration necessitates recompilation
It’s not worth recompilation.

A little further in the text, the capabilities that a regular procedural linker provides, which are everywhere and beyond which it has not yet gone, namely, the admissible transformations are listed.

Then, by chance, this list continues with another list of transformations, for those classes with inheritance. The object's private variable can be added, the class hierarchy can change. Anything that does not require changing the source code should not require recompilation. Such work was done in the IBM Object Technology Group (Austin).

And finally, in RRBC there is a table in which SOM is compared with alternatives (Delta / C ++, OBI - I am not familiar, but it was interesting to find out). In this table, I really

It is pleasantly pleased that the authors are familiar with CLOS and not only! In the table by one item (migrate metaclass constraint downward) CLOS is inferior to SOM. This problem (metaclass incompatibility) is discussed in more detail in, for example, Reflections on Metaclass Programming in SOM. The bottom line is that it is expected that the descendant metaclass will be a descendant of the parent metaclass, otherwise metaclass incompatibility. With explicit metaclasses, this becomes possible. Given the variability of the class hierarchy and, without forgetting the motto of the SOM, it becomes clear that what comes from the hands of CLOS will not get away from the hands of the SOM.

In SOM 2.0, the original solution to the problem is applied: the metaclass specified in the IDL class is now not an exact indication of the metaclass for this class, but only a limitation. The class metaclass must be a descendant of the metaclasses of each parent, as well as a descendant of the metaclass specified in the class declaration. If one of these metaclasses satisfies all the requirements, it is taken. Otherwise, the SOM runtime decides to cross all the required metaclasses in order to obtain the minimally satisfying metaclass.

At the same time, this document explains what these metaclasses are. I will retell on the example of Delphi and Java, in which metaclasses are implicit.

So, there are in both Delphi and Java, in addition to the methods of the object, also class methods. Delphi also has virtual constructors. As for Delphi, there is a TClass, declared as a class of TObject. Every time a class method or a virtual constructor is added to the Delphi class, this would be similar to the inheritance of the metaclass with the addition of these methods to the SOM. In Delphi and Java, metaclasses are implicit, and the chain of their inheritance almost mirrors the chain of inheritance of classes. If no new class methods have been added, we can assume that in this case the parent's metaclass is taken without changes. TClass and other class of ... in Delphi do not behave like ordinary objects. TObject has, for example, TObject.Dispatch, but for variables of type TClass, this method cannot be called. And any other method of the TObject object cannot be called on variables of type TClass. TClass is not a TObject descendant, they are in other ways. In Java, a little different: there is java.lang.Class and it is really the heir of java.lang.Object with all that it implies. However, if a class has a method, and we got into the hands of an instance of java.lang.Class representing a descendant of this class, then it will not be possible to call some method on such an instance. A class – like – object does not have the same methods that a class has –– simply.

Now, after I wrote how things are going in Delphi and Java, it should be clear what metaclasses are: in SOM, classes – objects are full-fledged objects, and their methods are full-fledged methods of the object, as complete as in their copies. And since objects cannot simply exist as objects, they must be declared in the class of this
object. The class of the class is the metaclass. The metaclass itself usually has a SOMClass as its class, but even it, being a full-fledged object, may have some other class. Forcing the SOM runtime to cross metametaclasses if necessary for that.

In effect, inheritance is given a new dimension

Here is such a twin COM with support for inheritance.

I wrote a review of object systems , and SOM shines in the light of its capabilities.

And now two news:

Good: SOM has been ported to Windows NT as well. Other targets are problematic to use. AIX for PowerPC, OS / 2 is not enough for every PC emulator and costs money, Himalaya NonStop - and nothing to think about, Mac OS Classic - also somehow far away.

SOM version 3.0 was available free of charge in the form of the February beta of 1996 and the December release, from which several features that could not be brought to mind were cut out. For example, Direct-To-SOM allowed not .h to be made from .idl, but, on the contrary, .idl from .h. We write on a modified C ++ compiler, the resulting code uses SOM and due to this it becomes flexible. In contrast to Delta / C ++, other C ++ compilers and compilers of other programming languages ​​automatically become potential library consumers.

The bad: I can’t find SOMobjects 3.0 Developer's Toolkit for WinNT anywhere. Something happened in 1997 or 1998 so terrible that it would be okay for IBM to stop developing in this direction, but no, it was necessary to clean SOM from its back streets from everywhere. On FTP, I just found the documentation, but there are no files themselves. Only thanks to the Hobbes archive the version for OS / 2 is preserved, the rest is bye-bye. I put VisualAge C ++ 4.0, I thought it was bundled. No, it is not.

A few months ago I started to get in touch with people who both participated in the development and who themselves used, including the version for Windows. It's nice that the answer, you can still find someone, but they do not have these files. Especially kills me when

Ideas who could still have the file stay temporarily exhausted. As far as I can tell, on physical media, SOM 3.0 was not distributed separately. The CD-ROM must be available for both OS / 2, WinNT, and AIX. Judging by the file name som30os2.zip (all that was saved on the Internet), this is the version from the CD-ROM. Internet-sized files had other names: som30ox1.zip, som30ox2.zip and som30ox3.zip.

What's next?

First, with some interest in the SOM, there may be missing files. In my opinion, it is still relevant, even considering the need for versions for Linux and Mac OS X. I like the idea of ​​PE COFF executable files that can detect execution inside wine, download native OS versions wxWidgets or Qt and, using them, forget your roots. Even without having the SOM source code, you can be useful, and having a working SOM and working code using the SOM can help you create a compatible replacement. Linux wxWidgets so easily can not be used from the program that compiles to Windows. This is where the interlayer would be useful, and why not SOM?

Secondly, the SOM awareness itself is a matrix in the mind that influences decision making by developers. Those who developed GObject did not have such a matrix in their minds, and GObject did not grow in SOM.

UPD . File found: som30nt.zip !

The person who gave this file is in search of SOM 3.0 for AIX, and, in addition, developed an open replacement for SOM: somFree . I couldn’t unpack tardist for IRIX, asked to upload hosting to open source.

If you install VisualAge C ++ 4.0 for Win32, note that it can tolerate PATH on modern Windows. Environment variables must be backed up.

UPD2 . somFree at sourceforge . So far only for POSIX systems.

In the meantime, I managed to deal with IBM SOM on VAC ++ 4.0 and even managed to build and run animals using Borland C ++ 5.5 Free.

In the short term, I would like to lay out the joint IBM SOM & Borland C ++ 5.5 Free distribution, in which one could collect and see all the examples from the box and get answers to my questions personally, and not from journalistic propaganda articles. Executable files speak louder than words.