| Previous | Table of Contents | Next |
A regular value type satisfies the following syntax:
(17) <value_dcl> ::= <value_header> “{“ < value_element>* “}?
(18) <value_header> ::= [“custom? ] “valuetype? <identifier> [ <value_inheritance_spec> ]
(21) <value_element> ::= <export> | < state_member> | | <init_dcl>
3.9.1.1 Value Header
The value header consists of two elements:
1. The value type’s name and optional modifier specifying whether the value type uses custom marshaling.
2. An optional value inheritance specification. The value inheritance specification is described in the next section.
3.9.1.2 Value Element
A value can contain all the elements that an interface can as well as the definition of state members, and initializers for
that state.
3.9.1.3 Value Inheritance Specification
(19)<value_inheritance_spec> ::= [ “:? [ “truncatable? ] <value_name> { “,? <value_name> }* ] [ “supports? <interface_name>
{ “,? <interface_name> }* ]
(20) <value_name> ::= <scoped_name>
Each <value_name> and <interface_name> in a <value_inheritance_spec>
must denote previously defined value type or interface. See Section 3.9.5, “Valuetype
Inheritance,? on page 3-30 for the description of value type inheritance.
The truncatable modifier may not be used if the value type being defined is a custom value.
A valuetype that supports a local interface does not itself become local (i.e. unmarshalable) as a result of that support.
3.9.1.4 State Members
(22) <state_member> ::= ( “public? | “private? )<type_spec> <declarators> “;?
Each <state_member> defines an element of the state, which is marshaled and sent to the receiver when the value type is passed
as a parameter. A state member is either public or private. The annotation directs the language mapping to hide or expose
the different parts of the state to the clients of the value type. The private part of the state is only accessible to the
implementation code and the marshaling routines.
A valuetype that has a state member that is local (i.e. non-marshalable like a local interface), is itself rendered local.
That is, such valuetypes behave similar to local interfaces when an attempt is made to marshal them.
Note that certain programming languages may not have the built in facilities needed to distinguish between the public and
private members. In these cases, the language mapping specifies the rules that programmers are responsible for following.
3.9.1.5 Initializers
(23) <init_dcl> ::= “factory? <identifier>“(“ [ <init_param_decls> ] “)? [ <raises_expr> ] “;?
(24) <init_param_decls> ::= <init_param_decl> { “,? <init_param_decl> }*
(25) <init_param_decl> ::= <init_param_attribute> <param_type_spec> <simple_declarator>
(26) <init_param_attribute> ::= “in?
In order to ensure portability of value implementations, designers may also define the signatures of initializers (or constructors)
for non abstract value types. Syntactically these look like local operation signatures except that they are prefixed with
the keyword factory, have no return type, and must use only in parameters. There may be any number of factory declarations.
The names of the initializers are part of the name scope of the value type. Initializers defined in a valuetype are not inherited
by derived valuetypes, and hence the names of the initializers are free to be reused in a derived valuetype.
If no initializers are specified in IDL, the value type does not provide a portable way of creating a runtime instance of
its type. There is no default initializer. This allows the definition of IDL value types, which are not intended to be directly
instantiated by client code.
3.9.1.6 Value Type Example
interface Tree {void print()
};
valuetype WeightedBinaryTree {
// state definition private unsigned long weight; private WeightedBinaryTree left; private WeightedBinaryTree right;
// initializer factory init(in unsigned long w);
// local operationsWeightSeq pre_order();WeightSeq post_order();
};valuetype WTree: WeightedBinaryTree supports Tree {};