| Previous | Table of Contents | Next |
This section describes semantics when a value instance is passed as parameter in a CORBA invocation. It does not deal with
the case of calling another non-CORBA (i.e., local) programming method, which happens to have a parameter of the same type.
5.2.4.1 Value vs. Reference Semantics
Determination of whether a parameter is to be passed by value or reference is made by examining the parameter’s formal type
(i.e., the signature of the operation it is being passed to). If it is a value type then it is passed by value. If it is an
ordinary interface then it is passed by reference (the case today for all CORBA objects). This rule is simple and consistent
with the handling of the same situation in recursive state definitions or in structs.
In the case of abstract interfaces, the determination is made at runtime. See
Section 6.2, “Semantics of Abstract Interfaces,? on page 6-1 for a description of the
rules.
5.2.4.2 Sharing Semantics
In order to be expressive enough to describe arbitrary graphs, lattice, trees etc., value types support sharing and null semantics.
Instances of a value type can be shared by others across or within other instances. They can also be null. This is unlike
other IDL data types such as structs, unions, and sequences that can never be shared. The sharing of values within and between
the parameters to an operation, is preserved across an invocation; that is, the graph that is reconstructed in the receiving
context is structurally isomorphic to the sending context’s.
5.2.4.3 Identity Semantics
When an instance of the value type is passed as a parameter to an operation of a non-local interface, the effect in all cases
shall be as if an independent copy of the instance is instantiated in the receiving context. While certain implementation
optimizations are possible the net effect shall be as if the copy is a separate independent entity and there is no explicit
or implicit sharing of state. This applies to all valuetypes involved in the invocation, including those embedded in other
IDL datatypes or in an any. This notional copying occurs twice, once for in and inout parameters when the invocation is initiated,
and once again for inout, out and return parameters when the invocation completes. Optimization techniques such as copy on
write etc. must make sure that the semantics of copying as described above is preserved.
5.2.4.4 Any parameter type
When an instance of a value type is passed to an any, as with all cases of passing instances to an any, it is the responsibility
of the implementor to insert and extract the value according to the language mapping specification.