Editing IBM System Object Model (section)

==Comparison to compiled class libraries==
{{anchor|Comparison of support for compiled class libraries}}
<!-- Is this section valuable without the table? -->

SOM can be compared compiled libraries: <ref>{{cite book|author=Ira R. Forman and Scott Danforth|title=Putting Metaclasses to Work|year=1999|publisher=Addison-Wesley |isbn=0-201-43305-2}}<br />Chapter 11 "Release-to-Release Binary Compatibility", page 246<br />An article with identical name and similar contents of the same author can be found on the Web: [http://hobbes.nmsu.edu/h-viewer.php?dir=/pub/os2/doc&file=R2R_SOM.zip Release-to-Release Binary Compatibility] {{Webarchive|url=https://web.archive.org/web/20151003013313/http://hobbes.nmsu.edu/h-viewer.php?dir=%2Fpub%2Fos2%2Fdoc&file=R2R_SOM.zip |date=2015-10-03 }}</ref>

* [[Smalltalk]]
* [[Common Lisp Object System]] (CLOS)
* generic [[C++]]
* SGI Delta/C++
* Sun Object Binary Interface
* [[Objective-C]]
* [[Java (programming language)|Java]]

As of 2015, most of the information in the linked table is applicable to modern versions, except Objective-C 2.0 getting so called non-fragile instance variables. Some solutions remained experimental: SGI Delta/C++ or Sun OBI. Most approaches based on one programming language were phased out or were never used actively in the same way. For instance, Netscape Plugin Application Programming Interface ([[NPAPI]]) browser plugins were written using Java API initially (LiveConnect), but [[Java Virtual Machine]] (JVM) was later excluded from the chain. It can be seen as Java replaced with Cross Platform Component Object Model ([[XPCOM]]). [[Common Lisp Object System]] (CLOS) and Smalltalk are not known as being chain links like Java in LiveConnect. [[Objective-C]] is also not known much in this role and not known to be marketed this way, but its runtime is one of the most friendly to similar use cases.

Generic C++ is still being used in [[Qt (software)|Qt]] and the K Desktop Environment ([[KDE]]). Qt and KDE are notable for describing efforts it takes to maintain binary compatibility without special support in development tools.<ref>{{Cite web|url=https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C++|title=Policies/Binary Compatibility Issues With C++ - KDE Community Wiki|website=community.kde.org}}</ref>

[[GObject]] only aimed to avoid dependence on C++ compiler, but RRBC issues are the same as in generic C++.

Without special runtime many other programming languages will have the same issues, e.g., [[Delphi (programming language)|Delphi]], [[Ada (programming language)|Ada]]. It can be illustrated by so-called ''unprecedented approach'' it took to produce Delphi 2006 binary compatible Delphi 2007 release: [http://blogs.embarcadero.com/abauer/2007/02/24/32322 How to add a "published" property without breaking DCU compatibility] {{Webarchive|url=https://web.archive.org/web/20151208103747/http://blogs.embarcadero.com/abauer/2007/02/24/32322 |date=2015-12-08 }}

[[Objective-C]] is the most promising competitor to SOM (although not being actively marketed as multi-language platform), and SOM should preferably be compared to Objective-C as opposed to COM as it happened historically. With non-fragile instance variables in Objective-C 2.0 it is the best alternative amongst actively supported.

[[Component Object Model|COM]], [[XPCOM]] are being used actively, but they only manage interfaces, not implementations, and thus are not on the same level as SOM, [[GObject]] and [[Objective-C]]. [[Windows Runtime]] under closer look behaves much like COM. Its metadata description is based on .NET, but since WinRT does not contain special runtime to resolve RRBC issues, like in Objective-C or SOM, several restrictions had to be applied that limit WinRT on procedural level:

[https://docs.microsoft.com/en-us/cpp/cppcx/type-system-c-cx Type System (C++/CX)]

: A ref class that has a public constructor must be declared as sealed, to prevent further derivation.

[https://docs.microsoft.com/en-us/archive/msdn-magazine/2012/windows-8-special-issue/windows-runtime-components-windows-runtime-components-in-a-net-world Windows Runtime Components - Windows Runtime Components in a .NET World]

: Another restriction is that no generic public classes or interfaces can be exposed. Polymorphism isn't available to WinRT types, and the closest you can come is implementing WinRT interfaces; you must declare as sealed any classes that are publicly exposed by your Windows Runtime Component.