Previous | Table of Contents | Next |
The terminology that is used to describe value type inheritance is directly analogous to
that used to describe interface inheritance (see Section 3.8.5, “Interface Inheritance,?
on page 3-23).
The name scoping and name collision rules for valuetypes are identical to those for interfaces. In addition, no valuetype
may be specified as a direct abstract base of a derived valuetype more than once; it may be an indirect abstract base more
than once. See
Section 3.8.5, “Interface Inheritance,? on page 3-23 for a detailed description of
the analogous properties for interfaces.
Values may be derived from other values and can support an interface and any number of abstract interfaces.
Once implementation (state) is specified at a particular point in the inheritance hierarchy, all derived value types (which
must of course implement the state) may only derive from a single (concrete) value type. They can however derive from other
additional abstract values and support an additional interface.
The single immediate base concrete value type, if present, must be the first element specified in the inheritance list of
the value declaration’s IDL. It may be followed by other abstract values from which it inherits. The interface and abstract
interfaces that it supports are listed following the supports keyword.
While a valuetype may only directly support one interface, it is possible for the valuetype to support other interfaces as
well through inheritance. In this case, the supported interface must be derived, directly or indirectly, from each interface
that the valuetype supports through inheritance. This rule does not apply to abstract interfaces that the valuetype supports.
For example:
interface I1 { }; interface I2 { }; interface I3: I1, I2 { };
abstract valuetype V1 supports I1 { }; abstract valuetype V2 supports I2 { }; valuetype V3: V1, V2 supports I3 { }; // legal
valuetype V4: V1 supports I2 { }; // illegal
A stateful value that derives from another stateful value may specify that it is truncatable
. This means that it is to “truncate? (see Section 5.2.5.3, “Value instance
> Value type,? on page 5-5) an instance to be an instance of any of its truncatable
parent (stateful) value types under certain conditions. Note that all the intervening types in the inheritance hierarchy must
be truncatable in order for truncation to a particular type to be allowed.
Because custom values require an exact type match between the sending and receiving context, truncatable may not be specified
for a custom value type.
Non-custom value types may not (transitively) inherit from custom value types.
Boxed value types may not be derived from, nor may they derive from anything else.
These rules are summarized in the following table: Table 3-10 Allowable Inheritance Relationships
May inherit from: | Interface | Abstract Interface | Abstract Value | Stateful Value | Boxed value |
Interface | multiple | multiple | no | no | no |
Abstract Interface | no | multiple | no | no | no |
Abstract Value | supports single | supports multiple | multiple | no | no |
Stateful Value | supports single | supports multiple | multiple | single (may be truncatable) | no |
Boxed Value | no | no | no | no | no |