Learning to Love SOM
Volume Number: 11
Issue Number: 1
Column Tag: Foundation Technology
Learning To Love SOM 
Choosing it for OpenDoc was a no-brainer
By Jens Peter Alfke, Apple Computer, Inc.
The System Object Model (SOM) provides the object-oriented substrate used by
OpenDoc and by future versions of the Macintosh Toolbox. SOM is fairly complex,
relatively new on the Mac, and competes against other proprietary object models. It’s
not surprising, then, that there is some degree of apprehension and misinformation
surrounding it. In this article, I will give you the straight scoop on SOM.
Frankly, my own initial feelings toward SOM were not warm and fuzzy. After we
on the OpenDoc team decided to make the move to SOM, and I began reading about it and
thinking about the task of converting our existing code base, I was heard to ask Kurt
Piersol: “We’re all going to die, aren’t we?” Fortunately, I was wrong; and since then
I’ve come to like and respect SOM.
Why Is SOM Necessary?
Object-based shared libraries are a holy grail of software engineering, since they turn
code into black-box components that can be plugged together by programmers.
Unfortunately, existing object models have been either too slow and too hard to use
from existing code (e.g. Smalltalk), or insufficiently robust (e.g. C++.)
Fragile Base Classes
What do I mean by “insufficiently robust”? The technical term is fragile
base-classes, and what it means is that changes to a base class - such as adding methods
or instance variables - often break code that uses the base class, or makes subclasses
of it, until that client code is recompiled.
In other words, if I update my JensTools C++ class library from version 1.0 to
1.1, and users install the new version, all their apps that use it may crash until they
get new releases from the developers. Needless to say, this has impeded the use of
object-based shared libraries.
There are two ways around this. The first is to abandon key features of
object-oriented programming like inheritance and polymorphism. This is what
Microsoft’s Component Object Model (COM) does. What you’re left with is a system of
procedural dispatch tables that I find quite reminiscent of the Component Manager. I’ve
used the Component Manager extensively as part of developing AppleScript, and let me
say that it is not my favorite shared library solution. (For a much more detailed look
at how SOM and COM differ, read “SOM vs. COM” in the documentation folder on the
CD.)
The better solution is to attack the problem head on and fix it, which is what
researchers at IBM did in producing SOM. I won’t go into the gory details here, but by
abstracting the way object instantiation and method dispatch work, they were able to
produce an object model that is extremely robust and still efficient and fully
object-oriented.
In other words, by basing my JensTools library on SOM (though it’s still
implemented in C++) I am able to add new methods and/or change its internal
implementation while retaining full binary compatibility: when users install the new
version, their existing apps continue to work perfectly, while new clients can take
advantage of the new features.
Language and Compiler Neutrality
A frequently-mentioned advantage of SOM is that it can be used with any
programming language, once the appropriate interfaces and glue code are written. This
is because the SOM kernel isn’t based on any single object model, and has robust
enough support for almost any language (for instance, it supports metaclasses and
name-based dispatching, features found in Smalltalk but not in C++.) C and C++
support currently exist, with Smalltalk in the works.
Language neutrality is also sometimes disparaged; some see it as nothing more
than unnecessary support for exotic languages that no one uses. Setting aside the fact
that many large businesses are using Smalltalk, and that it would be damn cool to be
able to write OpenDoc parts in Dylan, what these critics don’t realize or admit is that
different C++ compilers might as well be different languages when it comes to their
runtime object model. Due to differences in vtable layout and parameter passing,
objects created by one C++ compiler generally cannot be used by client code compiled
by a different C++ compiler. On the Mac, cfront, Apple’s new Mr.C compiler,
Symantec C++ and Metrowerks’ C++ are all mutually incompatible.
This incompatibility causes headaches even with COM. A frequent trick used by
COM programs is to use a C++ vtable as a COM method table. By strange coincidence,
this works just fine with the vtables laid out by the Microsoft C++ compiler. But it
doesn’t work with most other C++ compilers, and users of those compilers are forced
to lay out the method tables by hand, which turns out to be a lot more difficult than
creating a SOM class (in fact, it’s a lot like the tables SOM builds internally and
thankfully hides from you.)
Cross-Platform Support
Implementations of SOM currently exist for OS/2, Unix, Windows, and now the
Macintosh (both 68k and native PowerPC, included on the OpenDoc CD.) Future targets
include Netware, IBM’s Workplace, MVS and OS/400. IBM plans to license SOM to
Component Integration Labs, so it will be available for other vendors to license.
Using SOM With C++
This adds up to a pretty compelling case for using SOM. There’s nothing else available
that supports real object-oriented programming, with strong binary compatibility,
language and compiler independence, that runs on all major operating systems.
Choosing it for OpenDoc was a no-brainer once we’d analyzed the alternatives.
Unfortunately you do give up some things when you use SOM from C++. SOM is
not tied to the C++ object model, and it doesn’t support some fancier C++ features like
templates and operator overloading (although it does do things C++ doesn’t, like
metaclasses and name-based dispatching.) SOM classes aren’t the same as C++ classes;
this isn’t apparent on the client side since you call methods of a SOM object exactly as
you would a C++ object, but a SOM class’ methods are implemented as procedural
functions, which adds a certain amount of “syntactic vinegar” to your implementation
(as my colleague Richard Rodseth puts it.)
Many of these drawbacks will be alleviated by direct-to-SOM C++ compilers.
These are compilers with a native understanding of the SOM object model, which make
creating a SOM class as simple as inheriting from SOMObject. Direct-to-SOM
compilers are already available for OS/2 and Windows, and may be on the Mac soon.
Until then, there are tricks you can use if you want to do your work closer to
normal C++. One that works well, and is used in the sample OpenDoc leaf part class
that comes with PartMaker, is to create a normal C++ class with basically the same
API as the SOM class you want to implement. Then the SOM class’ implementation
simply instantiates a matching object of the C++ class, and each SOM method calls the
corresponding C++ method. This incurs a little bit of extra overhead, but eases the
transition to SOM for someone familiar with C++.
Cool Features
SOM supports features you don’t ordinarily get with C++. For instance, you can
determine the class of an arbitrary SOM object at runtime, or check whether an object
descends from a particular class or implements a particular method. You can examine
all the methods defined by a particular class and send an arbitrary message to an object
given a string representing the method name. You can even add new methods to a class
at runtime. All this is possible because SOM supports metaclasses, a concept
originating in Smalltalk which means that SOM classes are real objects.
Building A SOM Class
The full process of implementing a SOM class consists of:
• Write an IDL file: a SOM header that declares your class’ interface. The class will
inherit from an existing SOM class (such as SOMObject, or ODPart for an
OpenDoc part handler). In the interface you add any extra methods and instance
variables that your part objects will need.
IDL stands for Interface Definition Language, a simple syntax for defining classes.
It’s part of the industry-standard CORBA architecture. Fortunately, IDL looks
very much like a C++ class definition, with a few extensions.
• Crank your IDL file through the SOM compiler. This translates your part’s
definition from the abstract IDL syntax into a C or C++ API, plus the appropriate
magic glue for the SOM runtime. The output is several binding files that you use
to build your part with C or C++.
• Fill out the implementation. One of the binding files generated is a .c or .cpp file
that contains a blank C or C++ implementation of your part: the method functions
are all there but their bodies are empty. You fill in the bodies with the actual
code for each method.
• Compile and link the implementation files. The implementation binding file and
any other source files you create are linked against the SOM library, and the
libraries of any other SOM classes you use or inherit from, to produce a shared
library that implements your class. You can use any compiler that knows how to
build CFM shared libraries, such as scpp or CodeWarrior PPC.
• Iterate. If you fix bugs or make other changes that just modify existing class
methods, or non-class code, all you need to do is recompile and relink. If you need
to change the class structure by adding methods or instance variables, you’ll need
to run the SOM compiler again. The (blank) new methods will be appended to
your implementation file without disturbing the existing C/C++ code.
Networked Objects
SOM has an extension called DSOM that supports distributed objects. It allows SOM
objects on different machines on a network (or in separate address spaces on one
machine) to talk to each other as though they were all running in the same process.
DSOM is pretty transparent to your code; you just have to avoid pitfalls like trying to
send a remote object a raw pointer to data.
DSOM already runs on OS/2 and will be ported to the Mac OS; we plan to support
it in the second release of OpenDoc to allow distributed parts, documents and other
services.
On a broader scale yet, DSOM is an implementation of CORBA, an industry
standard for distributed objects. This means that DSOM clients can interact with
non-SOM distributed applications from vendors like DEC and H/P, running on
workstations or mainframes. This gives SOM-based systems like OpenDoc a well
defined way to connect to large corporate databases, which may or may not excite you
but makes IS managers sit up and drool.
Conclusion
SOM is one of those things where you have to look at the big picture. Yes, it’s a bit of a
pain at the micro-level of individual lines of code. But alternatives like COM, which
may seem simpler at first, turn out to be more complicated when used with some
compilers, and too limited to support true object-oriented programming. And SOM
becomes extremely cool at the larger scale of reusable and robust shared class
libraries, and positively mind-bending with its prospects of distributed objects and
Net-spanning applications.