Introduction to SOM
by Prokushev
The System Object Model (SOM) is a language neutral object model. The main advantage of SOM is the possibility to implement classes in any language which supports DLL creation or usage. The only predefined thing for such a model is the interface, as described in terms of the SOM Interface Definition Language, which can be translated to a corresponding language binding. Classes are represented in binary form. In language-specific object models, classes exist only virtually until compilation. For example, such a language could be C++, Delphi, Pascal or others. Actually, inheritance is implemented during runtime, like in true object-oriented languages like Smalltalk. Instances of classes are represented by object. Actually, objects of the same class share the same code. Code can be stored either in a DLL or in an EXE. Most usable is a DLL that can contain one or more classes. A DLL, in terms of SOM, named as class library. Most SOM functionality (except implementation of core logic) is implemented with a class library.
By default, OS/2 is shipped with a lot of general class libraries. Some of them are used every day and every minute, others not so often. Later we will briefly look at all of them.
Class libraries include:
- SOM Kernel
- Interface Repository Framework
- Metaclass Framework
- Event Management Framework
- Distributed SOM
- Sockets classes
- Replication Framework
- Persistent Framework
- Emitter Framework
- Collection Classes
- Workplace Shell Classes/XWorkplace Classes (XWP not present in IBM's OS/2)
- Multimedia Classes/CWMM Classes (not present in IBM's OS/2)
The most notable classes (from a user's point of view) are the Workplace Shell Classes. Desktop objects are SOM at work. Every day users use SOM objects and most of them like it.
SOM objects can be manipulated easily. Using the power of Object REXX, SOM users and programmers can do fantastic things without any problems. WPS can be easily customised and manipulated with Object REXX.
Another powerful set of classes are the OpenDoc Classes. They allow one to have highly integrated and user-friendly applications. If programmers would support OpenDoc then we could have lots of good applications (sic - no "application" term in OpenDoc words!). Neither monsters like OpenOffice or Lotus SmartSuite, nor applications like GIMP any more. Only components which allow one to build documents with very-very impressive content by easy operations. So, in the future, we'll try to review OpenDoc classes closely.
Don't forget about DSOM classes - an implementation of CORBA specification. Not the latest, but we can move forward and extend DSOM classes to support most (or all) features of current CORBA specification. It is also possible. SOM is an open model. Most classes and methods can be easily extended or replaced.
Don't forget about other object models, either. Most notable is XPCOM. Mozilla users use XPCOM every time. It's supported by DOM. XPCOM can be wrapped by SOM classes and reused by OS/2 programmers. It's another topic for future reviews.
Remember Java. Java classes and objects can be accessed via SOM. Mixing portable and native solutions allows us to have fantastic things. Native interface and cross-platform background. And vice versa.
We can do all of this, we must do all of it. We must learn things such as SOM. Really, things are not as hard as we may think.
Let's create our first SOM class. It is easy.
- Write the interface
- Create binding
- Write class implementation
- Use class
Nothing hard. All too easy...
Contents
Requirements
- SOM Compiler
- Watcom C compiler 32-bit (wcc386)
Write interface
The class interface must be described using the SOM Interface Definition Language (IDL). Some developers use only implementation language to describe class interface (sic). Such an approach is ugly and incorrect. Doing so, they close their classes to others (Note: one may derive the IDL file from the implementation but it's cumbersome. On the other hand using a Direct-To-SOM compiler does have/had advantages. Nowadays, with the death of VAC++ the best way indeed is to use just IDL so one of the other available compilers can be used). Use the SOM IDL and nothing else. It's clear. It's easy. It's useful.
Let's create a file called "demo.idl" with the following text inside:
#include <somcls.idl>
// include base classes
interface Demo : SOMObject
// Class Demo with parent SOMObject
{
attribute string DemoWord;
// Very-very useful data
void sayDemoWord();
// Very-very useful method
};
Is it hard? No!
Create bindings
In short, use SOM Compiler:
sc -s"h;ih;c" demo.idl
Result:
demo.h demo.ih demo.c
Is it hard? No!
Write class implementation
Ok. We have demo.c. Let's play the game:
/*
* This file was generated by the SOM Compiler and Emitter Framework.
* Generated using template emitter:
* SOM Emitter emitctm: 2.23.1.9
*/
#ifndef SOM_Module_demo_Source
#define SOM_Module_demo_Source
#endif
#define Demo_Class_Source
#include "demo.ih"
/*
* Very-very useful method
*/
SOM_Scope void SOMLINK sayDemoWord(Demo *somSelf, Environment *ev)
{
DemoData *somThis = DemoGetData(somSelf);
DemoMethodDebug("Demo","sayDemoWord");
printf("Write %s\n",_get_DemoWord(somSelf, ev));
}
Is it hard? No! Let's compile the demo (don't forget to check include paths):
wcc386 demo.c
Use class
Do we need code which we can't use? No! Let's use it!
Let's create a text file named "test.c" and include the following code:
#include "demo.h"
int main(int argc, char *argv[])
{
// Get environment info
Environment *ev = somGetGlobalEnvironment();
// Create demo1 and demo2 objects
Demo *demo1 = DemoNew();
Demo *demo2 = DemoNew();
// Set DemoWord attribute of objects
Demo__set_DemoWord(demo1, ev, "123");
Demo__set_DemoWord(demo2, ev, "321");
// Call sayDemoWord method of objects
Demo_sayDemoWord(demo1, ev);
Demo_sayDemoWord(demo2, ev);
// Destroy objects
_somFree(demo1);
_somFree(demo2);
// Finish
return 0;
}
Was it hard? No!
Let's create demo:
wcc386 test.c wlink file demo.obj file test.obj library somtk.lib name test.exe
Run it! All must be OK. It's easy.
