IDL Translation Issues

• Any tie class has a data member that references the implementation object to which ties delegate operations. This data member is usually a C++ pointer or reference. In the case of a p-tie class, however, it must be a d_Ref.
• Code to support the management of p-ties by the ODA library must be generated within every p-tie class. In our implementation, p-tie constructors and destructors perform ODA-related actions. Moreover, each p-tie class makes available to the ODA library a static function for p-tie instantiation.

The constructor of a p-tie class embeds into the p-tie's id a stringfied d_Ref to the p-tie's implementation object. It also registers the p-tie with the ODA library; the p-tie will be eventually unregistered by its destructor. The p-tie instantiation function receives a d_Ref to a persistent implementation object and creates a new p-tie to this object.

Special translation requirements do not necessarily mean another IDL translator. Our ODA implementation actually employs the IDL translator provided by the ORB, complementing it with macros. The object implementor annotates the server code with ODA-defined directives, which macro-expand into p-tie class definitions. No changes are made to any files generated by the IDL translator: ODA directives are placed only in user-written files, and typically within server headers. In what follows, an ODA-generated function (ODA-generated class) is a function (class) defined by the macro expansion of an ODA directive.