[Top] [Prev] [Next] [Bottom]
Mapping of OMG IDL to Smalltalk
20
This chapter describes the mapping of OMG IDL constructs to Smalltalk constructs.
20.1 Mapping Summary
TABLE 30. on page 20-1 provides a brief description of the mapping of OMG IDL constructs to the Smalltalk language, and where in this chapter they are discussed.
TABLE 30. Summary of this Chapter
OMG IDL Construct
|
Smalltalk Mapping
|
Where Discussed
|
---|
Interface
|
Set of messages that Smalltalk objects which represent object references must respond to. The set of messages corresponds to the attributes and operations defined in the interface and inherited interfaces.
|
Section 20.3, "Mapping for Interfaces," on page 20-3
|
Object Reference
|
Smalltalk object that represents a CORBA object. The Smalltalk object must respond to all messages defined by a CORBA object's interface.
|
Section 20.5, "Mapping for Objects," on page 20-3
|
Operation
|
Smalltalk message.
|
Section 20.17, "Mapping for Operations," on page 20-10
|
Attribute
|
Smalltalk message.
|
Section 20.7, "Mapping for Attributes," on page 20-4
|
Constant
|
Smalltalk objects available in the CORBAConstants dictionary.
|
Section 20.7.1, "Mapping for Constants," on page 20-5
|
Integral Type
|
Smalltalk objects that conform to the Integer class.
|
Section 20.8, "Mapping for Basic Data Types," on page 20-5
|
Floating Point Type
|
Smalltalk objects which conform to the Float class.
|
Described in Section 20.8, "Mapping for Basic Data Types," on page 20-5
|
Boolean Type
|
Smalltalk true or false objects.
|
Described in Section 20.8, "Mapping for Basic Data Types," on page 20-5.
|
Enumeration Type
|
Smalltalk objects which conform to the CORBAEnum protocol.
|
Section 20.10, "Mapping for Enums," on page 20-7
|
Any Type
|
Smalltalk objects that can be mapped into an OMG IDL type.
|
Section 20.9, "Mapping for the Any Type," on page 20-7
|
Structure Type
|
Smalltalk object that conforms to the Dictionary class.
|
Section 20.11, "Mapping for Struct Types," on page 20-8.
|
Union Type
|
Smalltalk object that maps to the possible value types of the OMG IDL union or that conform to the CORBAUnion protocol.
|
Section 20.12, "Mapping for Union Types," on page 20-8.
|
Sequence Type
|
Smalltalk object that conforms to the OrderedCollection class.
|
Section 20.13, "Mapping for Sequence Types," on page 20-10
|
String Type
|
Smalltalk object that conforms to the String class.
|
Section 20.14, "Mapping for String Types," on page 20-10
|
Array Type
|
Smalltalk object that conforms to the Array class.
|
Section 20.15, "Mapping for Array Types," on page 20-10
|
Exception Type
|
Smalltalk object that conforms to the Dictionary class.
|
Section 20.16, "Mapping for Exception Types," on page 20-10
|
20.2 Conversion of Names to Smalltalk Identifiers
The use of underscore characters in OMG IDL identifiers is not allowed in all Smalltalk language implementations. Thus, a conversion algorithm is required to convert names used in OMG IDL to valid Smalltalk identifiers.
To convert an OMG IDL identifier to a Smalltalk identifier, remove each underscore and capitalize the following letter (if it exists). In order to eliminate possible ambiguities which may result from these conventions, an explicit naming mechanism must also be provided by the implementation. For example, the #pragma directive could be used.
For example, the OMG IDL identifiers:
add_to_copy_map
describe_contents
become Smalltalk identifiers
addToCopyMap
describeContents
Smalltalk implementations generally require that class names and global variables have an uppercase first letter, while other names have a lowercase first letter.
20.3 Mapping for Interfaces
Each OMG IDL interface defines the operations that object references with that interface must support. In Smalltalk, each OMG IDL interface defines the methods that object references with that interface must respond to.
Implementations are free to map each OMG IDL interface to a separate Smalltalk class, map all OMG IDL interfaces to a single Smalltalk class, or map arbitrary Smalltalk classes to OMG IDL interfaces.
20.4 Memory Usage
One of the design goals is to make every Smalltalk object used in the mapping a pure Smalltalk object: namely datatypes used in mappings do not point to operating system defined memory. This design goal permits the mapping and users of the mapping to ignore memory management issues, since Smalltalk handles this itself (via garbage collection). Smalltalk objects which are used as object references may contain pointers to operating system memory, and so must be freed in an explicit manner.
20.5 Mapping for Objects
A CORBA object is represented in Smalltalk as a Smalltalk object called an object reference. The object must respond to all messages defined by that CORBA object's interface.
An object reference can have a value which indicates that it represents no CORBA object. This value is the standard Smalltalk value nil.
20.6 Invocation of Operations
OMG IDL and Smalltalk message syntaxes both allow zero or more input parameters to be supplied in a request. For return values, Smalltalk methods yield a single result object, whereas OMG IDL allows an optional result and zero or more out or inout parameters to be returned from an invocation. In this binding, the non-void result of an operation is returned as the result of the corresponding Smalltalk method, whereas out and inout parameters are to be communicated back to the caller via instances of a class conforming to the CORBAParameter protocol, passed as explicit parameters.
For example, the following operations in OMG IDL:
boolean definesProperty(in string key);
void defines_property(
in string key,
out boolean is_defined);
are used as follows in the Smalltalk language:
aBool := self definesProperty: aString.
self
definesProperty: aString
isDefined: (aBool := nil asCORBAParameter).
As another example, these OMG IDL operations:
boolean has_property_protection(in string key,
out Protection pval);
ORBStatus create_request (in Context ctx,
in Identifier operation,
in NVList arg_list,
inout DynamicInvocation::NamedValue result,
out Request request,
in Flags req_flags);
would be invoked in the Smalltalk language as:
aBool := self
hasPropertyProtection: aString
pval: (protection := nil asCORBAParameter).
aStatus := ORBObject
createRequest: aContext
operation: anIdentifier
argList: anNVList
result: (result := aNamedValue asCORBAParameter)
request: (request := nil asCORBAParameter)
reqFlags: aFlags.
The return value of OMG IDL operations that are specified with a void return type is undefined.
20.7 Mapping for Attributes
OMG IDL attribute declarations are a shorthand mechanism to define pairs of simple accessing operations; one to get the value of the attribute and one to set it. Such accessing methods are common in Smalltalk programs as well, thus attribute declarations are mapped to standard methods to get and set the named attribute value, respectively.
For example:
attribute string title;
readonly attribute string my_name;
means that Smalltalk programmers can expect to use title and title: methods to get and set the title attribute of the CORBA object, and the myName method to retrieve the my_name attribute.
20.7.1 Mapping for Constants
OMG IDL allows constant expressions to be declared globally as well as in interface and module definitions. OMG IDL constant values are stored in a dictionary named CORBAConstants under the fully qualified name of the constant, not subject to the name conversion algorithm. The constants are accessed by sending the at: message to the dictionary with an instance of a String whose value is the fully qualified name.
For example, given the following OMG IDL specification,
module ApplicationBasics{
const CopyDepth shallow_cpy = 4;
};
the ApplicationBasics::shallow_cpy constant can be accessed with the following Smalltalk code
value := CORBAConstants at:
'::ApplicationBasics::shallow_cpy'.
After this call, the value variable will contain the integral value 4.
20.8 Mapping for Basic Data Types
The following basic datatypes are mapped into existing Smalltalk classes. In the case of short, unsigned short, long, unsigned long, float, double, and octet, the actual class used is left up to the implementation, for the following reasons:
short
An OMG IDL short integer falls in the range [-215,215-1]. In Smalltalk, a short is represented as an instance of an appropriate integral class.
long
An OMG IDL long integer falls in the range [-231,231-1]. In Smalltalk, a long is represented as an instance of an appropriate integral class.
unsigned short
An OMG IDL unsigned short integer falls in the range [0,216-1]. In Smalltalk, an unsigned short is represented as an instance of an appropriate integral class.
unsigned long
An OMG IDL unsigned long integer falls in the range [0,232-1]. In Smalltalk, an unsigned long is represented as an instance of an appropriate integral class.
float
An OMG IDL float conforms to the IEEE single-precision (32-bit) floating point standard (ANSI/IEEE Std 754-1985). In Smalltalk, a float is represented as an instance of an appropriate floating point class.
double
An OMG IDL double conforms to the IEEE double-precision (64-bit) floating point standard (ANSI/IEEE Std 754-1985). In Smalltalk, a double is represented as an instance of an appropriate floating point class.
char
An OMG IDL character holds an 8-bit quantity mapping to the ISO Latin-1 (8859.1) character set. In Smalltalk, a character is represented as an instance of Character.
boolean
An OMG IDL boolean may hold one of two values: TRUE or FALSE. In Smalltalk, a boolean is represented by the values true or false, respectively.
octet
An OMG IDL octet is an 8-bit quantity that undergoes no conversion during transmission. In Smalltalk, an octet is represented as an instance of an appropriate integral class with a value in the range [0,255].
20.9 Mapping for the Any Type
Due to the dynamic nature of Smalltalk, where the class of objects can be determined at runtime, an explicit mapping of the any type to a particular Smalltalk class is not required. Instead, wherever an any is required, the user may pass any Smalltalk object which can be mapped into an OMG IDL type. For instance, if an OMG IDL structure type is defined in an interface, a Dictionary for that structure type will be mapped. Instances of this class can be used wherever an any is expected, since that Smalltalk object can be mapped to the OMG IDL structure.
Likewise, when an any is returned as the result of an operation, the actual Smalltalk object which represents the value of the any data structure will be returned.
20.10 Mapping for Enums
OMG IDL enumerators are stored in a dictionary named CORBAConstants under the fully qualified name of the enumerator, not subject to the name conversion algorithm. The enumerators are accessed by sending the at: message to the dictionary with an instance of a String whose value is the fully qualified name.
These enumerator Smalltalk objects must support the CORBAEnum protocol, to allow enumerators of the same type to be compared. The order in which the enumerators are named in the specification of an enumeration defines the relative order of the enumerators. The protocol must support the following instance methods:
< aCORBAEnum
Answers true if the receiver is less than aCORBAEnum, otherwise answers false.
<= aCORBAEnum
Answers true if the receiver is less than or equal to aCORBAEnum, otherwise answers false.
= aCORBAEnum
Answers true if the receiver is equal to aCORBAEnum, otherwise answers false.
> aCORBAEnum
Answers true if the receiver is greater than aCORBAEnum, otherwise answers false.
>= aCORBAEnum
Answers true if the receiver is greater than or equal to aCORBAEnum, otherwise answers false.
For example, given the following OMG IDL specification,
module Graphics{
enum ChartStyle
{lineChart, barChart, stackedBarChart, pieChart};
};
the Graphics::lineChart enumeration value can be accessed with the following Smalltalk code
value := CORBAConstants at: '::Graphics::lineChart'.
After this call, the value variable is assigned to a Smalltalk object that can be compared with other enumeration values.
20.11 Mapping for Struct Types
An OMG IDL struct is mapped to an instance of the Dictionary class. The key for each OMG IDL struct member is an instance of Symbol whose value is the name of the element converted according to the algorithm in Section 20.2. For example, a structure with a field of my_field would be accessed by sending the at: message with the key #myField.
For example, given the following OMG IDL declaration:
struct Binding {
Name binding_name;
BindingType binding_type;
};
the binding_name element can be accessed as follows:
aBindingStruct at: #bindingName
and set as follows:
aBindingStruct at: #bindingName put: aName
20.12 Mapping for Union Types
For OMG IDL union types, two binding mechanisms are provided: an implicit binding and an explicit binding.1 The implicit binding takes maximum advantage of the dynamic nature of Smalltalk and is the least intrusive binding for the Smalltalk programmer. The explicit binding retains the value of the discriminator and provides greater control for the programmer.
Although the particular mechanism for choosing implicit vs. explicit binding semantics is implementation specific, all implementations must provide both mechanisms. Binding semantics is expected to be specifiable on a per-union declaration basis, for example using the #pragma directive.
20.12.1 Implicit Binding
Wherever a union is required, the user may pass any Smalltalk object that can be mapped to an OMG IDL type, and whose type matches one of the types of the values in the union. Consider the following example:
structure S { long x; long y; };
union U switch (short) {
case 1: S s;
case 2: long l;
default: char c;
};
In the example above, a Dictionary for structure S will be mapped. Instances of Dictionary with runtime elements as defined in structure S, integral numbers, or characters can be used wherever a union of type U is expected. In this example, instances of these classes can be mapped into one of the S, long, or char types, and an appropriate discriminator value can be determined at runtime.
Likewise, when an union is returned as the result of an operation, the actual Smalltalk object which represents the value of the union will be returned.
20.12.2 Explicit Binding
Use of the explicit binding will result in specific Smalltalk classes being accepted and returned by the ORB. Each union object must conform to the CORBAUnion protocol. This protocol must support the following instance methods:
discriminator
Answers the discriminator associated with the instance.
discriminator: anObject
Sets the discriminator associated with the instance.
value
Answers the value associated with the instance.
value: anObject
Sets the value associated with the instance
To create an object that supports the CORBAUnion protocol, the instance method asCORBAUnion: aDiscriminator can be invoked by any Smalltalk object. This method will return a Smalltalk object conforming to the CORBAUnion protocol, whose discriminator will be set to aDiscriminator and whose value will be set to the receiver of the message.
20.13 Mapping for Sequence Types
Instances of the OrderedCollection class are used to represent OMG IDL elements with the sequence type.
20.14 Mapping for String Types
Instances of the Smalltalk String class are used to represent OMG IDL elements with the string type.
20.15 Mapping for Array Types
Instances of the Smalltalk Array class are used to represent OMG IDL elements with the array type.
20.16 Mapping for Exception Types
Each defined exception type is mapped to an instance of the Dictionary class. See Section 20.20.1 for a complete description.
20.17 Mapping for Operations
OMG IDL operations having zero parameters map directly to Smalltalk unary messages, while OMG IDL operations having one or more parameters correspond to Smalltalk keyword messages. To determine the default selector for such an operation, begin with the OMG IDL operation identifier and concatenate the parameter name of each parameter followed by a colon, ignoring the first parameter. The mapped selector is subject to the identifier conversion algorithm.
For example, the following OMG IDL operations:
void add_to_copy_map(
in CORBA::ORBId id,
in LinkSet link_set);
void connect_push_supplier(
in EventComm::PushSupplier push_supplier);
void add_to_delete_map(
in CORBA::ORBId id,
in LinkSet link_set);
become selectors:
addToCopyMap:linkSet:
connectPushSupplier:
addToDeleteMap:linkSet:
20.18 Implicit Arguments to Operations
Unlike the C mapping, where an object reference, environment, and optional context must be passed as parameters to each operation, this Smalltalk mapping does not require these parameters to be passed to each operation.
The object reference is provided in the client code as the receiver of a message. So although it is not a parameter on the operation, it is a required part of the operation invocation.
This mapping defines the CORBAExceptionEvent protocol to convey exception information in place of the environment used in the C mapping. This protocol can either be mapped into native Smalltalk exceptions or used in cases where native Smalltalk exception handling is unavailable.
A context expression can be associated with the current Smalltalk process by sending the message corbaContext: to the current process, along with a valid context parameter. The current context can be retrieved by sending the corbaContext message to the current process.
The current process may be obtained by sending the message activeProcess to the Smalltalk global variable named Processor.
20.19 Argument Passing Considerations
All parameters passed into and returned from the Smalltalk methods used to invoke operations are allocated in memory maintained by the Smalltalk virtual machine. Thus, explicit free()ing of the memory is not required. The memory will be garbage collected when it is no longer referenced.
The only exception is object references. Since object references may contain pointers to memory allocated by the operating system, it is necessary for the user to explicitly free them when no longer needed. This is accomplished by using the operation release of the CORBA::Object interface.
20.20 Handling Exceptions
OMG IDL allows each operation definition to include information about the kinds of run-time errors which may be encountered. These are specified in an exception definition which declares an optional error structure which will be returned by the operation should an error be detected. Since Smalltalk exception handling classes are not yet standardized between existing implementations, a generalized mapping is provided.
In this binding, an IDL compiler creates exception objects and populates the CORBAConstants dictionary. These exception objects are accessed from the CORBAConstants dictionary by sending the at: message with an instance of a String whose value is the fully qualified name. Each exception object must conform to the CORBAExceptionEvent protocol. This protocol must support the following instance methods:
corbaHandle: aHandlerBlock do: aBlock
Exceptions may be handled by sending an exception object the message corbaHandle:do: with appropriate handler and scoping blocks as parameters. The aBlock parameter is the Smalltalk block to evaluate. It is passed no parameters. The aHandlerBlock parameter is a block to evaluate when an exception occurs. It has one parameter: a Smalltalk object which conforms to the CORBAExceptionValue protocol.
corbaRaise
Exceptions may be raised by sending an exception object the message corbaRaise.
corbaRaiseWith: aDictionary
Exceptions may be raised by sending an exception object the message corbaRaiseWith:. The parameter is expected to be an instance of the Smalltalk Dictionary class, as described below.
For example, given the following OMG IDL specification,
interface NamingContext {
...
exception NotEmpty {};
void destroy ()
raises (NotEmpty);
...
};
the NamingContext::NotEmpty exception can be raised as follows:
(CORBAConstants at: '::NamingContext::NotEmpty')
corbaRaise.
The exception can be handled in Smalltalk as follows:
(CORBAConstants at: '::NamingContext::NotEmpty')
corbaHandle: [:ev | "error handling logic here" ]
do: [aNamingContext destroy].
20.20.1 Exception Values
OMG IDL allows values to be returned as part of the exception. Exception values are constructed using instances of the Smalltalk Dictionary class. The keys of the dictionary are the names of the elements of the exception, the names of which are converted using the algorithm in Section 20.2, "Conversion of Names to Smalltalk Identifiers," on page 20-2. The following example illustrates how exception values are used:
interface NamingContext {
...
exception CannotProceed {
NamingContext cxt;
Name rest_of_name;
};
Object resolve (in Name n)
raises (CannotProceed);
...
};
would be raised in Smalltalk as follows:
(CORBAConstants at: '::NamingContext::CannotProceed')
corbaRaiseWith: (Dictionary
with: (Association key: #cxt value:
aNamingContext)
with: (Association key: #restOfName value:
aName)).
20.20.2 The CORBAExceptionValue protocol
When an exception is raised, the exception block is evaluated, passing it one argument which conforms to the CORBAExceptionValue protocol. This protocol must support the following instance messages:
corbaExceptionValue
Answers the Dictionary the exception was raised with.
Given the NamingContext interface defined in the previous section, the following code illustrates how exceptions are handled:
(CORBAConstants at: '::NamingContext::NotEmpty')
corbaHandle:[:ev |
cxt:=ev corbaExceptionValue at: #cxt.
restOfName :=ev corbaExceptionValue at:
#restOfName]
do:[aNamingContext destroy].
In this example, the cxt and restOfName variables will be set to the respective values from the exception structure, if the exception is raised.
[Top] [Prev] [Next] [Bottom]
1
Although not required, implementations may choose to provide both implicit and explicit mappings for other OMG IDL types, such as structs and sequences. In the explicit mapping, the OMG IDL type is mapped to a user specified Smalltalk class.
pubs@omg.org
Copyright © 1995, Object Management Group. All rights
reserved.