| Previous | Table of Contents | Next |
An interface can have attributes as well as operations; as such, attributes are defined as part of an interface. An attribute
definition is logically equivalent to declaring a pair of accessor functions; one to retrieve the value of the attribute and
one to set the value of the attribute.
The syntax for attribute declaration is:
(85) <attr_dcl> ::= <readonly_attr_spec> | <attr_spec>
(104) <readonly_attr_spec> ::= “readonly? “attribute? <param_type_spec> <readonly_attr_declarator> (105)<readonly_attr_declarator
>::= <simple_declarator> <raises_expr>
| <simple_declarator> { “,? <simple_declarator> }*
(106) <attr_spec> ::= “attribute? <param_type_spec> <attr_declarator>
(107) <attr_declarator> ::= <simple_declarator> <attr_raises_expr>
| <simple_declarator> { “,? <simple_declarator> }*
The optional readonly keyword indicates that there is only a single accessor function—the retrieve value function. Consider
the following example:
interface foo {enum material_t {rubber, glass};struct position_t {
float x, y;};
attribute float radius;attribute material_t material;readonly attribute position_t position;
};
The attribute declarations are equivalent to the following pseudo-specification fragment, assuming that one of the leading
‘_’s is removed by application of the
Escaped Identifier rule described in Section 3.2.3.1, “Escaped Identifiers,? on
page 3-7:
float __get_radius ();void __set_radius (in float r);material_t __get_material ();void __set_material (in material_t m);position_t __get_position ();
The actual accessor function names are language-mapping specific. The attribute name is subject to OMG IDL’s name scoping
rules; the accessor function names are guaranteed not to collide with any legal operation names specifiable in OMG IDL.
Attributes are inherited. An attribute name cannot be redefined to be a different type. See
Section 3.19, “CORBA Module,? on page 3-66 for more information on
redefinition constraints and the handling of ambiguity.