ic

User's Guide

Version 4.4.2

Chapters

2 OMG IDL

2.1  OMG IDL - Overview

The purpose of OMG IDL, Interface Definition Language, mapping is to act as translator between platforms and languages. An IDL specification is supposed to describe data types, object types etc.

Since the C and Java IC backends only supports a subset of the IDL types supported by the other backends, the mapping is divided into different parts. For more information about IDL to Erlang mapping, i.e., CORBA, plain Erlang and generic Erlang Server, see the Orber User's Guide. How to use the plain Erlang and generic Erlang Server is found in this User's Guide.

Reserved Compiler Names and Keywords

The use of some names is strongly discouraged due to ambiguities. However, the use of some names is prohibited when using the Erlang mapping , as they are strictly reserved for IC.

IC reserves all identifiers starting with OE_ and oe_ for internal use.

Note also, that an identifier in IDL can contain alphabetic, digits and underscore characters, but the first character must be alphabetic.

Using underscores in IDL names can lead to ambiguities due to the name mapping described above. It is advisable to avoid the use of underscores in identifiers.

The OMG defines a set of reserved words, shown below, for use as keywords. These may not be used as, for example, identifiers.

abstract double local raises typedef
any exception long readonly unsigned
attribute enum module sequence union
boolean factory native short ValueBase
case FALSE Object string valuetype
char fixed octet struct void
const float oneway supports wchar
context in out switch wstring
custom inout private TRUE
default interface public truncatable

Table 2.1:   OMG IDL keywords

The keywords listed above must be written exactly as shown. Any usage of identifiers that collide with a keyword is illegal. For example, long is a valid keyword; Long and LONG are illegal as keywords and identifiers. But, since the OMG must be able to expand the IDL grammar, it is possible to use Escaped Identifiers. For example, it is not unlikely that native have been used in IDL-specifications as identifiers. One option is to change all occurrences to myNative. Usually, it is necessary to change programming language code that depends upon that IDL as well. Since Escaped Identifiers just disable type checking (i.e. if it is a reserved word or not) and leaves everything else unchanged, it is only necessary to update the IDL-specification. To escape an identifier, simply prefix it with _. The following IDL-code is illegal:

typedef string native;
interface i {
   void foo(in native Arg);
   };
};
      

With Escaped Identifiers the code will look like:

typedef string _native;
interface i {
   void foo(in _native Arg);
   };
};