SOM Overview

SOM is a robust, language-neutral packaging technology for class libraries. SOM is not a programming language. One of the elements of SOM IS a language,--OIDL (or Object Interface Definition Language). OIDL is a description-language for specifying the external interface to a class. OIDL is NOT a programming language; there is no way to implement a class with OIDL, or with SOM. For that, you need to use a programming language, eg, C, C++, Smalltalk, Eiffel, FORTRAN, and a set of "SOM bindings."

These "SOM language bindings" may be formal or informal. A formal binding is one produced by a tool (such as the SOM Compiler). This would be the typical type of SOM binding most programmers will be using. An informal binding might be a hand crafted binding for some specialized use of SOM.

It is important to understand the relationship between SOM and the Workplace Shell. SOM is a packaging technology. The Workplace Shell is a product that is packaged using the SOM packaging technology. This is analogous to the relationship between some programming language, like C++, and some particular application programmed in that programming language. The analogy breaks down a bit, because SOM is not a language, but the basic idea of the relationship between the tool and the product built using the tool is accurate.

Why do we say SOM is language-neutral? Basically for the same reason that one says that the transport layer in a communications diagram is protocol-neutral. That is, whether you use the network to run sessions, conversations, datagrams, or what-have-you, you need a way to ship the bytes across the wire without prejudicing their contents. All of the higher-level protocols must at least agree on this mechanism. Ultimately SOM is a mechanism, which was deliberately designed to be both rich enough to be capable of expressing a wide range of different OO semantics and also lean enough to be able to deliver high performance, so that a C++ class, packaged with SOM would be just as viable as an Objective-C or Object-REXX object.

If you think such a mechanism is unnecessary, consider this from an operating system context. OOP is such an attractive paradigm that it is almost unreasonable to insist that a modern GUI-style operating system interface be built on any other basis. But once you do decide to build your operating system using object technology, how do you keep it from becoming a single-language operating system? One cannot affort to develop a large scale operating system which can only be used from one language regardless of how good one thinks that language is.

As we all know, large software systems and particularly operating systems experience considerable evolution over their lifetime. Unfortunately many OO languages turn out to be unpleasantly fragile when a change must be made to the implementation of a class. Try changing the size of a C++ object and see how many binary client programs manage to remain unbroken. As a packaging technology for classes SOM offers 4 specific degrees of freedom for class implementers that are guaranteed not to break client programs that are already compiled. With SOM you may
 * 1) Add new methods to classes
 * 2) Add, change, or delete instance variables
 * 3) Insert new classes above your class in the inheritance hierarchy
 * 4) Relocate methods upward in the class hierarchy.

In other words, an implementer is free to make the very kinds of changes that evolving OO systems routinely exhibit WITHOUT BREAKING CLIENT BINARIES! But SOM is not magic; it too offers design tradeoffs. If you choose to make an instance variable public (so that it can be directly accessed by client programs), then you have also committed to making it a permanent part of your interface. But at least the decision to do so must be made deliberately.

So we see that SOM is intended to solve a very real and pressing problem. Namely, there was no reasonable way to develop class libraries that have properties similar to our current procedure libraries. SOM is not intended to compete with C++, Smalltalk, C, or any programming language. Because the current SOM release only directly supports C, you might think that we are advocating that people use C + SOM instead of C++. Nothing could be further from the truth. We have prototyped C++ support for SOM and expect to have SOM support shipped soon. Once C++ support is available then C++ would be the language of choice for many programmers wishing to build system class libraries. However, C++ without the SOM runtime is not usable for building binary class libraries, because:
 * 1) The binaries of one C++ compiler are not acceptable to another.
 * 2) An application that binds to a C++ DLL would need to be recompiled if the DLL was replaced with a new release, unless the developers made almost no changes to their implementation.
 * 3) Use of the libraries from any other language (even C) would be almost impossible.

When C++ is combined with SOM these problems are removed. Thus making it practical to use OO technology for things like the workplace shell, OLE-like facilities, etc. This is the promise of SOM. We give you the capability to package function in this way.

We expect to follow SOM with many class libraries, but these will not be part of SOM, -- they will be part of OS/2 (or AIX or products by themselves, or ...), because this is the real goal: --- OO technology as part of a system, not --- --- part of a programming language        ---

We realize that SOM will evolve, and much of this evolution is already planned. In particular, we are planning multiple inheritance, C++ bindings, AIX support, OMG CORBA compliance (including an IDL compiler with a user-extensible backend, an Interface Repository, and an ORB), and over time, various other things. In addition, a variety of SOM-based frameworks are planned that cover such topics as persistence, replication, GUI, foundation classes, etc.