SOM IDL and the SOM Compiler

This chapter first discusses how to define SOM classes and then describes the SOM Compiler. To allow a class of objects to be implemented in one programming language and used in another (that is, to allow a SOM class to be language neutral), the interface to objects of this class must be specified separately from the objects' implementation.

To summarize: As a first step, a file known as the .idl file is used to declare classes and their methods, using SOM's language#neutral Interface Definition Language (IDL). Next, the SOM Compiler is run on the .idl file to produce a template implementation file that contains stub method procedures for the new and overridden methods; this preliminary code corresponds to the computer language that will implement the class. Then, the class implementer fills in the stub procedures with code that implements the methods (or redefines overridden methods) and sets instance data. (This implementation process is the subject of Chapter 5, "Implementing Classes in SOM.") At this point, the implementation file can be compiled and linked with a client program that uses it (as described in Chapter 3, "Using SOM Classes in Client Programs").

Syntax for SOM IDL and the SOM Compiler are presented in this chapter, along with helpful information for using them correctly.

Interface vs Implementation

The interface to a class of objects contains the information that a client must know to use an object-namely, the names of its attributes and the signatures of its methods. The interface is described in a formal language independent of the programming language used to implement the object's methods. In SOM, the formal language used to define object interfaces is the Interface Definition Language (IDL), standardized by CORBA.

The implementation of a class of objects (that is, the procedures that implement methods) is written in the implementer's preferred programming language. This language can be object-oriented (for instance, C++) or procedural (for instance, C).

A completely implemented class definition, then, consists of two main files:

• An IDL specification of the interface to instances of the class (the interface definition file (or .idl file) and
• Method procedures written in the implementer's language of choice (the implementation file).

The interface definition file has an .idl extension, as noted. The implementation file, however, has an extension specific to the language in which it is written. For example, implementations written in C have a .c extension, and implementations written in C++ have a .C (for AIX) or .cpp (for OS/2) extension.

To assist users in implementing SOM classes, the SOMobjects Toolkit provides a SOM Compiler. The SOM Compiler takes as input an object interface definition file (the .idl file) and produces a set of binding files that make it convenient to implement and use a SOM class whose instances are objects that support the defined interface. The binding files and their purposes are as follows:

• An implementation template that serves as a guide for how the implementation file for the class should look. The class implementer fills in this template file with language-specific code to implement the methods that are available on the class' instances.
• Header files to be included (a) in the class's implementation file and (b) in client programs that use the class.

These binding files produced by the SOM Compiler bridge the gap between SOM and the object model used in object-oriented languages (such as C++), and they allow SOM to be used with non-object-oriented languages (such as C). The SOM Compiler currently produces binding files for the C and C++ programming languages. SOM can also be used with other programming languages; the bindings simply offer a more convenient programmer's interface to SOM. Vendors of other languages may also offer SOM bindings; check with your language vendor for possible SOM support.

The subsequent sections of this chapter provide full syntax for SOM IDL and the SOM Compiler.

SOM Interface Definition Language

This section describes the syntax of SOM's Interface Definition Language (SOM IDL). SOM IDL complies with CORBA's standard for IDL; it also adds constructs specific to SOM. (For more information on the CORBA standard for IDL, see The Common Object Request Broker: Architecture and Specification, published by Object Management Group and x/Open.) The full grammar for SOM IDL is given in Appendix C. Instructions for converting existing OIDL-syntax files to IDL are given in Appendix B. The current section describes the syntax and semantics of SOM IDL using the following conventions:

Constants (words to be used literally, such as keywords) appear in bold. User-supplied elements appear in italics.

{ } Groups related items together as a single item. 
[] Encloses an optional item. 
* Indicates zero or more repetitions of the preceding item. 
+ Indicates one or more repetitions of the preceding item. 
| Separates alternatives. 
_ Within a set of alternatives, an underscore indicates the default, if defined. 

IDL is a formal language used to describe object interfaces. Because, in SOM, objects are implemented as instances of classes, an IDL object interface definition specifies for a class of objects what methods (operations) are available, their return types, and their parameter types. For this reason, we often speak of an IDL specification for a class (as opposed to simply an object interface). Constructs specific to SOM discussed below further strengthen this connection between SOM classes and the IDL language.

IDL generally follows the same lexical rules as C and C++, with some exceptions. In particular:

• IDL uses the ISO Latin-1 (8859.1) character set (as per the CORBA standard).
• White space is ignored except as token delimiters.
• C and C++ comment styles are supported.
• IDL supports standard C/C++ preprocessing, including macro substitution, conditional compilation, and source file inclusion.
• Identifiers (user-defined names for methods, attributes, instance variables, and so on) are composed of alphanumeric and underscore characters, (with the first character alphabetic) and can be of arbitrary length, up to an operating-system limit of about 250 characters.
• Identifiers must be spelled consistently with respect to case throughout a specification.
• Identifiers that differ only in case yield a compilation error.
• There is a single name space for identifiers (thus, using the same identifier for a constant and a class name within the same naming scope, for example, yields a compilation error).
• Integer, floating point, character, and string literals are defined just as in C and C++.

The terms listed in the Keywords table are reserved keywords and may not be used otherwise. Keywords must be spelled using upper- and lower-case characters exactly as shown in the table. For example, "void" is correct, but "Void" yields a compilation error.

A typical IDL specification for a single class, residing in a single .idl file, has the following form. (Also see the later section, "Module declarations to define multiple interfaces in an .idl file.") The order is unimportant, except that names must be declared (or forward referenced) before they are referenced. The subsequent topics of this section describe the requirements for these specifications:

Include directives (optional)

Type declarations (optional)

Constant declarations (optional)

Exception declarations (optional)

Interface declaration (optional)

Module declaration (optional)

Keywords for SOM IDL

┌─────────────────────────┬─────────────────────────┬─────────────────────────┐
│any                      │FALSE                    │readonly                 │
├─────────────────────────┼─────────────────────────┼─────────────────────────┤
│attribute                │float                    │sequence                 │
├─────────────────────────┼─────────────────────────┼─────────────────────────┤
│boolean                  │implementation           │short                    │
├─────────────────────────┼─────────────────────────┼─────────────────────────┤
│case                     │in                       │string                   │
├─────────────────────────┼─────────────────────────┼─────────────────────────┤
│char                     │inout                    │struct                   │
├─────────────────────────┼─────────────────────────┼─────────────────────────┤
│class                    │interface                │switch                   │
├─────────────────────────┼─────────────────────────┼─────────────────────────┤
│const                    │long                     │TRUE                     │
├─────────────────────────┼─────────────────────────┼─────────────────────────┤
│context                  │module                   │TypeCode                 │
├─────────────────────────┼─────────────────────────┼─────────────────────────┤
│default                  │octet                    │typedef                  │
├─────────────────────────┼─────────────────────────┼─────────────────────────┤
│double                   │oneway                   │unsigned                 │
├─────────────────────────┼─────────────────────────┼─────────────────────────┤
│enum                     │out                      │union                    │
├─────────────────────────┼─────────────────────────┼─────────────────────────┤
│exception                │raises                   │void                     │
└─────────────────────────┴─────────────────────────┴─────────────────────────┘

Type and constant declarations

           Integral types
           Floating point types
           Character type
           Boolean type
           Octet type
           Any type
           Constructed types
               Union type 
           Template types (sequences and strings)
           Arrays
           Pointers
           Object types 

Method (operation) declarations

           Oneway keyword
           Parameter list
           Raises expression
           Context expression 

Implementation statements

           Modifier statements
           SOM Compiler unqualified modifiers
           SOM Compiler qualified modifiers
           Passthru statements
           Declaring instance variables and staticdata variables
           Introducing non-IDL data types or classes 

Scooping and name resolution

           Name usage in client programs 

Extensions to CORBA IDL permitted by SOM IDL

           Pointer '*' types
           Unsigned types
           Implementation section
           Comment processing
           Generated header files 

The SOM Compiler

       Generating binding files
       Environment variables affecting the SOM Compiler
       Running the SOM Compiler