Introduction to SOM

Introdution to SOM (System Object Model)

by Prokushev

System Object Model (SOM, SOMObjects) 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. Interface, as described in terms of 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. Instance of class 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. A DLL can contain one or more classes. A DLL, in terms of SOM, named as classes library. Most SOM functionality (except implementation of core logic) is implemented with a class library.

By default, eComStation shipped a lot of general class libraries. Some of them 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 managment Framework
• Distributed SOM
• Sockets classes
• Replication Framework
• Presistent Framework
• Emitter Framework
• Collection Classes
• Workplace Shell Classes/XWorkplace Classes
• Multimedia Classes/CWMM Classes

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 easely customized and manipulated with Object REXX.

Another powerfull set of classes is OpenDoc Classes. Not part of eComStation system, they allow one to have higly integrated and user-friendly applications. If programmers will support OpenDoc then we can have lot of good application (sick! No application term in OpenDoc word!). No monsters like Open Office or Lotus Smart Suite. No applications like GIMP. Only components which allows one to build documents with very-very impressive content by easy operations. It is possible. It is the future of OS/2 and eComStation. We can make our word better. So, in future, we'll try to review OpenDoc classes closely.

Don't forget about DSOM classes - 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 DOM support. 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 vise versa.

We can do all of it, we must do all of it. We must learn such things as SOM. Really, things not so hard as we think.

Lets create our first SOM class. It is easy.

• Step 1. Write interface
• Step 2. Create binding
• Step 3. Write class implementation
• Step 4. Use class

Nothing hard. All too easy...

Write interface

The class interface must be described using Interface Definition Language. Some developers use only implementation language to describe class interface (sick!). Such an approach is ugly and incorrect. Doing so, they close their classes to other. Use Interface Definition Language and nothing more. It's clear. It's easy. It's useful.

#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!

#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.