The IDL/Lisp Standard and ORBLink

The CORBA IDL/LISP proposed standard mapping allows the implementor flexibility in the implementation of various types and functions. The purpose of this document is to describe the choices we have made.

Sequence handling

This ORB always unmarshals values corresponding to the IDL sequence type as vectors. However, a list may be used anywhere a sequence is expected.

float and double types

corba:float, corresponding to the IDL float type, denotes the type single-float.

corba:double, corresponding to the IDL double type, denotes the type double-float.

Operation mapping

ORBLink implements CORBA operations as generic functions. An operation named "foo" will be mapped to a method on a standard generic function named OP:FOO.

The signature of the generic function is (T &REST ARGS).

User code may rely on the fact that OP:FOO is a funcallable object and may freely use auxiliary methods with such objects. However, Franz may change the low-level implementation of such functions in the future and user code should not rely on the metaclass or the signature of such generic functions.

Unimplemented features

The following aspects of the CORBA Core are unimplemented:
  1. DII/DSI
  2. Wide strings, wide characters [no longer true as of Orblink 2.2.03]
  3. Extended numeric types (long double, long long)
  4. Fixed types
  5. POA [no longer true]
  6. Contexts

Note on on enum types

According to the CORBA 2.2 specification, an enum type does not begin a new naming scope. This means that enum members themselves define a new type in the namespace of the IDL construct containing the enum type definition. The CORBA 2.3 specification may change this counter-intuitive rule. In any case, we follow the CORBA 2.2 specification so that users must make sure that enum members do not conflict with names in a containing scope.