OS/2 Professional/OS2PRO194.ISO/os2/prgramer/info/som_ov.txt

Text File | 1992-09-22 | 6.0 KB | 113 lines

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 prducts 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 inheritence, 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.