| Previous | Table of Contents | Next |
The basic notion is relatively simple. A value type is, in some sense, half way between a “regular? IDL interface type and
a struct. The use of a value type is a signal from the designer that some additional properties (state) and implementation
details be specified beyond that of an interface type. Specification of this information puts some additional constraints
on the implementation choices beyond that of interface types. This is reflected in both the semantics specified herein, and
in the language mappings.
An essential property of value types is that their implementations are always local. That is, the explicit use of value type
in a concrete programming language is always guaranteed to use a local implementation, and will not require a remote call.
They have no identity (their value is their identity) and they are not “registered? with the ORB.
There are two kinds of value types, concrete (or stateful) value types, and abstract (stateless) ones. As explained below
the essential characteristics of both are the same. The differences between them result from the differences in the way they
are mapped in the language mappings. In this specification the semantics of value types apply to both kinds, unless specifically
stated otherwise.
Concrete (stateful) values add to the expressive power of (IDL) structs by supporting:
• single derivation (from other value types)
• supports a single non-abstract interface
• arbitrary recursive value type definitions, with sharing semantics providing the ability to define lists, trees, lattices and more generally arbitrary graphs using value types.
• null value semantics
When an instance of such a type is passed as a parameter, the sending context marshals the state (data) and passes it to the
receiving context. The receiving context instantiates a new instance using the information in the GIOP request and unmarshals
the state. It is assumed that the receiving context has available to it an implementation that is consistent with the sender’s
(i.e., only needs the state information), or that it can somehow download a usable implementation. Provision is made in the
on-the-wire format to support the carrying of an optional call back object (CodeBase) to the sending context, which enables
such downloading when it is appropriate.
It should be noted that it is possible to define a concrete value type with an empty state as a degenerate case.