| Previous | Table of Contents | Next |
The substitutability requirements for CORBA require the definition of what happens when an instance of a derived value type
is passed as a parameter that is declared to be a base value type or an instance of a value type that supports an interface
is passed as a parameter that is declared as the interface type.
There are three cases to consider: the parameter type is a regular interface, the parameter type is an abstract interface,
and the parameter type is a value type.
5.2.5.1 Value instance -> Interface type
A value type that supports a regular interface is not a subtype of that interface, and hence cannot be substituted for that
interface in an invocation parameter. In this case an object reference corresponding to the value type instance that has been
registered with the ORB must be obtained and this object reference must be used as the actual parameter. Different language
mappings provide different facilities to aid in such parameter passing.
5.2.5.2 Value Instance -> Abstract interface type
A value type that supports an abstract interface is a subtype of that interface, and can be substituted for that interface
in an invocation parameter.
5.2.5.3 Value instance -> Value type
In this case the receiving context is expecting to receive a value type. If the receiving context currently has the appropriate
implementation class then there is no problem.
If the receiving context does not currently hold an implementation with which to reconstruct the original type then the following
algorithm is used to find such an implementation:
1. Load - Attempt to load (locally in C/C++, possibly remotely in Java and other “portable? languages) the real type of the object (with its methods). If this succeeds, OK.
2. Truncate - Truncate the type of the object to the base type (if specified as truncatable in the IDL). Truncation can never lead to faulty programs because, from a structural point view base types structurally subsume a derived type and an object created in the receiving context bears no relationship with the original one. However, it might be semantically puzzling, as the derived type may completely reinterpret the meaning of the state of the base. For that reason a derived value needs to indicate if it is safe to truncate to its immediate non-abstract parent.
3. Raise Exception - If none of these work or are possible, then raise the NO_IMPLEMENT exception with standard minor code 1.
Truncatability is a transitive property.
Example
valuetype EmployeeRecord { // note this is not a CORBA::Object // state definition private string name; private string email;
private string SSN; // initializer factory init(in string name, in string SSN);
};
valuetype ManagerRecord: truncatable EmployeeRecord { // state definition private sequence<EmployeeRecord> direct_reports;
};