View source for Introduction to SOM

Introduction to SOM ([http://en.wikipedia.org/wiki/System_Object_Model 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, 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. 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 (and OS/2) are shipped with 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:

* [[OS2_API:SOM_Kernel|SOM Kernel]]
* [[OS2_API:SOM_IR|Interface Repository Framework]]
* [[OS2_API:SOM_DSOM#Metaclass_Framework|Metaclass Framework]]
* [[OS2_API:SOM_DSOM#Event_Management_Framework|Event managment Framework]]
* [[OS2_API:SOM_DSOM#DSOM.2FCORBA_Framework|Distributed SOM]]
* [[OS2_API:SOM_DSOM#Sockects_interface|Sockets classes]]
* [[OS2_API:SOM_DSOM#Replication_Framework|Replication Framework]]
* [[OS2_API:SOM_DSOM#Persistence_Framework|Presistent Framework]]
* [[Emitter Framework]]
* [[OS2_API:SOM_DSOM#Collection_classes|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 easely customized and manipulated with [[Object REXX]].

Another powerful set of classes is [[OpenDoc Classes]]. Not part of eComStation system, they allow one to have higly 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!). No monsters like Open Office or Lotus Smart Suite, no applications like GIMP any more. Only components which allow 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 the future, we'll try to review [[OpenDoc classes]] closely.

Don't forget about [[OS2_API:SOM_DSOM#DSOM.2FCORBA_Framework|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 viceversa.

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.

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

Nothing hard. All too easy...

=== Requirements ===
* [[SOM Compiler]]
* Watcom C compiler 32Bits (wcc386)

=== Write interface ===

The class interface must be described using [[the SOM Interface Definition Language]].
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 Interface Definition Language]] 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.

[[Category:SOM Articles]]