Mapping of OMG IDL to Ada 23 Contents This chapter contains the following sections. Section Title Page “Overview” 23-1 “Mapping Summary” 23-2 “Other Mapping Requirements” 23-5 “Lexical Mapping” 23-6 “Mapping of IDL to Ada” 23-10 “Mapping of Pseudo-Objects to Ada” 23-36 “Server-Side Mapping” 23-43 “Predefined Language Environment: Subsystem CORBA” 23-45 “Glossary of Ada Terms” 23-65 23.1 Overview The Ada language mapping provides the ability to access and implement CORBA objects in programs written in the Ada programming language (ISO/IEC 8652:1995). The mapping is based on the definition of the ORB in Common Object Request Broker: Architecture and Specification. The Ada language mapping uses the Ada language’s support for object oriented programming—packages, tagged types, and late binding—to present the object model described by the CORBA Architecture and Specification. CORBA V2.2 February 1998 23-1 23 The mapping specifies how CORBA objects (objects defined by IDL) are mapped to Ada packages and types. Each CORBA object is represented by an Ada tagged type reference. The operations of mapped CORBA objects are invoked by calling primitive subprograms defined in the package associated with that object’s CORBA interface. 23.1.1 Ada Implementation Requirements The mapping is believed to map completely and correctly any legal set of definitions in the IDL language to equivalent Ada definitions. The style of this mapping is natural for Ada and does not impact the reliability either of CORBA implementations or of clients or servers built on the ORB. The mapping itself does not require any changes to CORBA. 23.2 Mapping Summary Table23-1 summarizes the mapping of IDL constructs to Ada constructs. The following sections elaborate on each of these constructs. Table23-1 Summary of IDL Constructs to Ada Constructs IDL construct Ada construct Source file Library package Module Package (Child Package if nested) Interface Package with Tagged Type (Child Package if nested) Operation Primitive Subprogram Attribute “Set_attribute” and “Get_attribute” subpro- grams Inheritance: Single Tagged Type Inheritance Multiple Tagged Type Inheritance for first parent; cover functions with explicit widening mmmmand narrowing for subsequent parents Data types Ada types Exception Exception and record type 23.2.1 Interfaces and Tagged Types Client Side An IDL interface is mapped to an Ada package and a tagged reference type. The package name will be mapped from the interface name. If the interface has an enclosing scope (including a subsystem “virtual scope”), the mapped package will be a child package of the package mapped from the enclosing scope. The mapped package will contain the definition of a tagged reference type for the object class, derived from the reference type mapped from the parent IDL interface, if the IDL interface is a 23-2 CORBA V2.2 February 1998 23 subclass of another interface, or from an implementation-defined common root reference type, CORBA.Object.Ref, if the interface is not a subclass of another interface. This allows implementations of the mapping to offer automatic memory management and improves the separation of an interface and its implementation. The mapped package also contains definitions of constants, types, exceptions, and subprograms mapped from the definitions in the interface or inherited by it. Forward Declarations Forward declarations result in the instantiation of a generic package that provides a reference type that can be used until the interface is fully defined. The generic instantiation also defines a nested generic package that is instantiated within the full interface definition and provides conversion from the forward reference type to the full interface reference type and vice versa. This allows clients that hold references to the interface to convert explicitly those references to the forward reference type when required. Server Side The server-side mapping of an IDL interface creates a “.Impl” package that is a child of the client-side interface package. The package contains a declaration for the Object type, derived from the parent interface's object type or from a common root, CORBA.Object.Object, with a (possibly private) extension provided to allow the implementor to specify the actual data components of the object. 23.2.2 Operations Each operation maps to an Ada subprogram with name mapped from the operation name. In the client-side package, the first (controlling) parameter to the operation is the reference type for the interface. In the server side package, the controlling parameter is a general access-to-variable type. Operations with non-void result type that have only in-mode parameters are mapped to Ada functions returning an Ada type mapped from the operation result type; otherwise, operations are mapped to Ada procedures. A non-void result is returned by an added parameter to a procedure. 23.2.3 Attributes The Ada mapping models attributes as pairs of primitive subprograms declared in an interface package, one to set and one to get the attribute value. An attribute may be read-only, in which case only a retrieval function is provided. The name of the retrieval function is formed by prepending “Get_” to the attribute name. “Set_” is used to form the names of attribute set procedures. Like operations, a first controlling parameter is added. In client-side packages, the controlling parameter is of the reference type, while in server-side packages, it is a general access-to-variable type. CORBA V2.2 Mapping Summary February 1998 23-3 23 23.2.4 Inheritance IDL inheritance allows an interface to be derived from other interfaces. IDL inheritance is interface inheritance; the only associated semantics at the IDL level are that a child object reference has “access to” all the operations of any of its parents. Reflection of IDL inheritance in mapped code is a function solely of the language mapping. Single inheritance of IDL interfaces is directly mapped to inheritance in the Ada mapping (i.e., an interface with a parent is mapped to a tagged type that is derived from the tagged type mapped from the parent). The definitions of types, constants, and exceptions in the parent package are renamed or subtyped so that they are also “inherited” in accordance with the IDL semantics. The client-side of multiple inheritance in IDL maps to a single Ref tagged type, as with single inheritance, where the parent type is the first interface listed in the IDL parent interface list. The IDL compiler must generate additional primitive subprograms that correspond to the operations inherited from the second and subsequent parent interfaces listed in the IDL. 23.2.5 Data Types The mapping of types is summarized in Table23-2. Table23-2 Summary of Mapping Types Type(s) Mapping Arithmetic Corresponding Ada arithmetic types char Character boolean Boolean octet Interfaces.Unsigned_8 any CORBA.Any (implementation defined) struct record with corresponding components union discriminated record enum enumerated type sequence instantiation of pre-defined generic pack- age string Ada.Strings type Arrays array types 23.2.6 Exceptions An IDL exception maps directly to an Ada exception declaration of the same name. The optional body of an exception maps to a type that is an extension of a predefined abstract tagged type. The components of the record will be mapped from the member 23-4 CORBA V2.2 February 1998 23 of the exception body in a manner similar to the mapping of record types. Implementors must provide a function that returns the exception members from the Ada-provided Exception_Occurrence for each exception type. 23.2.7 Names and Scoping Modules are mapped directly to packages. Nested modules map to child packages of the packages mapped from the enclosing module. This mapping supports the introduction of a subsystem name that serves as a root virtual module for all declarations in one or more files. When specified, subsystems create a library package. Files (actually inclusion streams) create a package to contain the “bare” definitions defined in IDL's global scope. The package name is formed from the concatenation of the file name and _IDL_File. Lexical inclusion (#include) is mapped to with clauses for the packages mapped from the included files, modules, and interfaces. 23.3 Other Mapping Requirements 23.3.1 Implementation Considerations The Ada language mapping can be implemented in a number of ways. Stub packages, ORB packages, and datatype packages may vary between implementations of the mapping. This is a natural consequence of using an object-oriented programming language—the implementation of a package should not be visible to its user. 23.3.2 Calling Convention Like IDL, Ada allows the passing of parameters to operations using in, out, and in out modes and returning values as results. The Ada language mapping preserves these in/out modes in an operation’s subprogram specification. Parameters may be passed by value or by reference. 23.3.3 Memory Management The mapping permits automatic memory management; however, the language mapping does not specify what kind, if any, of memory management facility is provided by an implementation. 23.3.4 Tasking The mapping encourages implementors to provide tasking-safe access to CORBA services. CORBA V2.2 Other Mapping Requirements February 1998 23-5 23 23.4 Lexical Mapping This section specifies the mapping of IDL identifiers, literals, and constant expressions. 23.4.1 Mapping of Identifiers IDL identifiers follow rules similar to those of Ada but are more strict with regard to case (identifiers that differ only in case are disallowed) and less restrictive regarding the use of underscores. A conforming implementation shall map identifiers by the following rules: • Where “_” is followed by another underscore, replace the second underscore with the character ‘U’. • Where “_” is at the end of an identifier, add the character ’U’ after the underscore. • When an IDL identifier collides with an Ada reserved word, insert the string “IDL_” before the identifier. These rules cannot guarantee that name clashes will not occur. Implementations may implement additional rules to further resolve name clashes. 23.4.2 Mapping of Literals IDL literals shall be mapped to lexically equivalent Ada literals or semantically equivalent expressions. The following sections describe the lexical mapping of IDL literals to Ada literals. This information may be used to provide semantic interpretation of the literals found in IDL constant expressions in order to calculate the value of an IDL constant or as the basis for translating those literals into equivalent Ada literals. Integer Literals IDL supports decimal, octal, and hexadecimal integer literals. A decimal literal consists of a sequence of digits that does not begin with 0 (zero). Decimal literals are lexically equivalent to Ada literal values and shall be mapped "as is." An octal literal consists of a leading ‘0’ followed by a sequence of octal digits (0 .. 7). Octal constants shall be lexically mapped by prepending “8#” and appending “#” to the IDL literal. The leading zero in the IDL literal may be deleted or kept. A hexadecimal literal consists of “0x” or “0X” followed by a sequence of hexadecimal digits (0 .. 9, [a|A] .. [f|F]). Hexadecimal literals shall be lexically mapped to Ada literals by deleting the leading “0x” or “0X,” prepending “16#” and appending “#.” Floating-Point Literals An IDL floating-point literal consists of an integer part, a decimal point, a fraction part, an ‘e’ or ‘E,’ and an optionally signed integer exponent. 23-6 CORBA V2.2 February 1998 23 Note – IDL before version 1.2 allowed an optional type suffix [f, F, d, or D]. The integer and fraction parts consist of sequences of decimal digits. Either the integer part or the fraction part, but not both, may be missing. Either the decimal point and the fractional part or the ‘e’ (or ‘E’) and the exponent, but not both, may be missing. A lexically equivalent floating point literal shall be formed by appending to the integer part (or “0” if the integer part is missing): • a “.” (decimal point), the fraction part (or “0” if the fraction part is missing), or • an “E” and the exponent (or “0” if the exponent is missing). Optionally, the ending “E0” may be left off if the IDL did not have an exponent. Note – For implementations choosing a mapping for the pre-1.2 optional type suffix, the following rule should be observed: If a type suffix is appended, the above construction should be appended to the Ada mapping of the type suffix followed by “’(“, and a closing “)” should be appended. Character Literals IDL character literals are single graphic characters or escape sequences enclosed by single quotes. The first form is lexically equivalent to an Ada character literal. Table23-3 supplies lexical equivalents for the defined escape sequences. Equivalent character literals may also be used, but are not recommended when used in concatenation expressions. Table23-3 Lexical Equivalents for the Defined Escape Sequences Description IDL Escape ISO 646 Ada Lexical Mapping Sequence Octal Value newline \n 012 Ada.Characters.Latin_1.LF horizontal tab \t 011 Ada.Characters.Latin_1.HT vertical tab \v 013 Ada.Characters.Latin_1.VT backspace \b 010 Ada.Characters.Latin_1.BS carriage return \r 015 Ada.Characters.Latin_1.CR form feed \f 014 Ada.Characters.Latin_1.FF alert \a 007 Ada.Characters.Latin_1.BEL backslash \\ 134 Ada.Characters.Latin_1.Reverse_ Solidus question mark \? 077 Ada.Characters.Latin_1.Question single quote \’ 047 Ada.Characters.Latin_1.Apostrophe CORBA V2.2 Lexical Mapping February 1998 23-7 23 Table23-3 Lexical Equivalents for the Defined Escape Sequences Description IDL Escape ISO 646 Ada Lexical Mapping Sequence Octal Value double quote \” 042 Ada.Characters.Latin_1.Quotation octal number \ooo ooo Character’val(8#ooo#) hex number \xhh Octal equiva- Character’val(16#hh#) lent to the hexadecimal number hh String Literals An IDL string literal is a sequence of IDL characters surrounded by double quotes. Adjacent string literals are concatenated. Within a string, the double quote character must be preceded by a ‘\’. A string literal may not contain the “nul” character. Lexically equivalent Ada string literals shall be formed as follows: • If the string literal does not contain escape sequences (does not contain ‘\’), the IDL literal is lexically equivalent to a valid Ada literal. • If the IDL literal contains escape sequences, the string must be partitioned into substrings. As each embedded escape sequence is encountered, three partitions must be formed: • one containing a substring with the contents of the string before the escape sequence, • one containing the escape sequence only, and • one containing the remainder of the string. The remainder of the string is checked (iteratively) for additional escape sequences. The substrings containing an escape sequence must be replaced by their lexically equivalent Ada character literals as specified in the preceding section. These substrings must be concatenated together (using the Ada “&” operator) in the original order. Finally, adjacent strings must be concatenated. 23.4.3 Mapping of Constant Expressions In IDL, constant expressions are used to define the values of constants in constant declarations. A subset, those expressions that evaluate to positive integer values, may also be found as: • the maximum length of a bounded sequence, • the maximum length of a bounded string, or as • the fixed array size in complex declarators. An IDL constant expression shall be mapped to an Ada static expression or a literal with the same value as the IDL constant expression. The value of the IDL expression must be interpreted according to the syntax and semantics in the Common Object 23-8 CORBA V2.2 February 1998 23 Request Broker: Architecture and Specification. The mapping may be accomplished by interpreting the IDL constant expression yielding an equivalent Ada literal of the required type or by building an expression containing operations on literals, scoped names, and interim results that mimic the form and semantics of the IDL literal expression and yield the same value. Mapping of Operators Table23-4 provides the correspondence between IDL operators in a valid constant expression and semantically equivalent Ada operators. This information may be used to provide semantic interpretation of the operators found in IDL constant expressions or as the basis for translating expressions containing those operators into equivalent Ada expressions. Table23-4 IDL Operators and Semantically Equivalent Ada Operators IDL IDL Applicable Types Ada Supported by Ada Types Operator symbol Operator Integer Floating Boolean Modular Signed Floating point Integer Integer Point (cid:214) (cid:214) (cid:214) or | or (cid:214) (cid:214) (cid:214) xor ^ xor (cid:214) (cid:214) (cid:214) and & and (cid:214) (cid:214) shift << Interfaces. Shift_Left (cid:214) (cid:214) >> Interfaces. Shift_Right (cid:214) (cid:214) (cid:214) (cid:214) (cid:214) add + + (cid:214) (cid:214) (cid:214) (cid:214) (cid:214) - - (cid:214) (cid:214) (cid:214) (cid:214) (cid:214) multiply * * (cid:214) (cid:214) (cid:214) (cid:214) (cid:214) / / (cid:214) (cid:214) (cid:214) (cid:214) % rem (cid:214) (cid:214) (cid:214) (cid:214) (cid:214) unary - - (cid:214) (cid:214) (cid:214) (cid:214) (cid:214) + + (cid:214) (cid:214) (cid:214) (cid:214) ~ not -(value - 1) Note that the following IDL semantics (from the CORBA spec) requires some coercion of types. Differences in applicability of operators to types may force some additional type conversions to obtain Ada expressions semantically equivalent to the IDL expressions. Mixed type expressions (e.g., integers mixed with floats) are illegal. An integer constant expression is evaluated as unsigned long unless it contains a negated integer literal or the name of an integer constant with a negative value. In the latter case, the constant expression is evaluated as CORBA V2.2 Lexical Mapping February 1998 23-9 23 signed long. The computed value is coerced back to the target type in constant initializers. It is an error if the computed value exceeds the range of the evaluated-as type (long or unsigned long). All floating-point literals are double, all floating-point constants are coerced to double, and all floating-point expression are computed as doubles. The computed double value is coerced back to the target type in constant initializers. It is an error if this coercion fails or if any intermediate values (when evaluating the expression) exceed the range of double.” 23.5 Mapping of IDL to Ada This section specifies the syntactic and semantic mapping of OMG IDL to Ada. Unless noted, the mapping is applicable to both client-side and server-side interfaces. Mapping considerations unique to the server-side interface are specified in “Server-Side Mapping” on page23-43. 23.5.1 Names Identifiers The lexical mapping of IDL identifiers is specified in “Mapping of Identifiers” on page23-6. All identifiers in the Ada interfaces generated from IDL shall be mapped from the corresponding IDL identifiers. Scoped Names Name scopes in IDL have the following corresponding Ada named declarative regions: • The subsystem name, if specified, forms an Ada library package. • The “global” name space of IDL files are mapped to Ada “_IDL_File” library packages. • IDL modules are mapped to Ada child packages of the packages representing their enclosing scope. • IDL interfaces are mapped to Ada child packages of the packages representing their enclosing scope. • All IDL constructs scoped to an interface are accessed via Ada expanded names. For example, if a type mode were defined in interface printer, then the Ada type would be referred to as Printer.Mode. These mappings allow the expanded name mechanism in Ada to be used to build Ada identifiers corresponding to IDL scoped names. 23-10 CORBA V2.2 February 1998