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.