Editing IBM System Object Model (section)

==Comparison to COM==

SOM is often compared to [[component object model]] (COM). Both support a library format that can be used from more than one language. 

Some consider SOM to be more robust since it only supports a language-neutral calling mechanism that is similar to COM [[late binding]]. COM also supports [[early binding]], a.k.a. custom interface, that is less safe although more performant. It allows a client to access an object via a function table that is compatible with [[C (programming)|C]] and therefore compatible with the binary layout of the virtual table of C++ objects (at least in Microsoft's C++ compiler). With a compatible C++ compiler, a custom interface can be defined as a pure virtual C++ class. The interface can be called by any language that can call C functions via a pointer. 

A risk of a custom interface is that an incompatibility can result in [[undefined behavior]]. In particular, if a version of the object is published with a modified custom interface, a client may crash. This is an example of the [[fragile base class]] problem. To prevent the problem, a rule for COM development is that once published, a custom interface cannot be changed. To add or change the exposed features of an object, it can implement additional custom interfaces.

SOM avoid this issue by providing only late binding {{endash}} allowing the run-time linker to re-build the table on the fly. This way, changes to the underlying libraries are resolved when they are loaded into programs.

SOM is more robust in terms of supporting object-oriented (OO) features. Whereas COM essentially defines a cut-down version of C++ to program to, SOM supports almost all common features. It also supports some less common features such as [[multiple inheritance]], [[metaclass]]es and [[dynamic dispatch]]ing, which had led most SOM/COM-like systems <!--what does SOM/COM-like mean?--> to be simpler at the cost of supporting fewer languages. Multi-language support was important to IBM as they wanted to support both [[Smalltalk]] ([[single inheritance]] and [[dynamic dispatch]]) with [[C++]] ([[multiple inheritance]] and fixed dispatch).

A notable difference is support for inheritance. COM does not. Although may think it odd that Microsoft produced an object library technology that could not support such a fundamental concept of OO programming; the main reason is that it is difficult to know where a base class exists in memory where libraries are loaded in a order unknown at design time. COM demands that the programmer specify the exact base class at compile time, making it impossible to insert other derived classes in the middle; at least in other COM libraries.

SOM instead uses an algorithm, looking for potential base classes by following the inheritance tree and stopping at the first one that matches. This is the idea behind inheritance in most cases. The downside to this approach is that it is possible that new versions of this base class may no longer work even if the [[application programming interface|API]] remains the same. This possibility exists in any program, not only those using a shared library, but a problem can become difficult to resolve if it exists in someone else's code. In SOM, the only solution is testing of new versions of libraries.

While SOM and COM were contrapositioned by IBM, they were not mutually exclusive. In 1995 Novell contributed ComponentGlue<ref>{{Cite web|url=http://www.novell.com/news/press/archive/1995/02/pr00063.html|title=Novell To Ship New OpenDoc(TM) Developer Release &#124; Micro Focus|website=www.novell.com}}</ref> technology to [[OpenDoc]] for Windows. This technology provided different means to integrate between COM and SOM components. In particular, SOM objects can be made available to OLE2 applications by either late binding bridge (based on IDispatch) or COM interfaces having higher performance. In essence, SOM classes are implementing COM interfaces this way.

Similar technologies, such as [[Distributed Objects Everywhere]], also support full inheritance. [[Portable Distributed Objects]] avoided these issues via a strong versioning system, allowing library authors to ship new versions along with the old, thereby guaranteeing [[backward compatibility]] at the cost of disk space.