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)

(optional)

(optional)

(optional)

(optional)

(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                     │
└─────────────────────────┴─────────────────────────┴─────────────────────────┘