To provide a better understanding of the IDL to Common Lisp mapping, we can take a look at the result of applying the mapping to the file bank.idl.
Parsing the IDL defines a package BANKINGDEMO.
As an example of the mapping scheme, the following subsections examine the Common Lisp counterparts of some of the more representative IDL declarations from the file bank.idl.
The IDL types string, long, and unsigned long are mapped to the Common Lisp types corba:string, corba:long, and corba:ulong, which are typedefs for the types string, integer, and integer.
The IDL interfaces account, checkingAccount, and bank map to the Common Lisp classes BankingDemo:account, BankingDemo:checkingAccount, and BankingDemo:bank.
Notice how IDL interface inheritance (checkingAccount: account) maps naturally onto Common Lisp class inheritance: the class BankingDemo:checkingAccount is defined as a subclass of BankingDemo:account.
The read-only balance attribute of an IDL account gives rise to the Common Lisp generic functions:
op:balance
If we had omitted the readonly keyword from the definition of the balance attribute, the mapping would have introduced an additional generic setter function:
(setf op:balance)
The IDL operation credit is mapped to the Common Lisp generic function:
op:credit
In IDL, the credit operation is defined within the account interface, declaring it to be an operation on account objects. The Common Lisp language binding adopts the convention that an operation's target object should be passed as the first argument of the corresponding Common Lisp generic function. Thus the first parameter of the generic function op:credit is an object of type BankingDemo:account.
The operation's in and inout arguments become the remaining parameters of the corresponding Common Lisp generic function. In this case, the credit operation specifies a single in parameter, in unsigned long amount, that determines the second and only other parameter, amount, of the op:credit generic function.
The operation's result type, and any other parameters declared as out or inout, become results of the corresponding Common Lisp generic function. In this case, because the result type of credit is void, and the operation has no out or inout parameters, op:credit has an empty result list.
The IDL exception refusal maps onto the Common Lisp class BankingDemo:account/refusal. Its member, reason string;, maps onto a slot reason of type string.
Note that BankingDemo:account/refusal is a subclass of CORBA:userexception and, by inheritance, of Common Lisp condition. This means that CORBA user exceptions can be raised on the server, and handled in the client, using the standard Common Lisp condition mechanism.
Developing Component Software with CORBA - 14 Feb 2015