Note the mandatory semi-colon following the closing bracket!
Within the body of the module, there will be one or more interface declarations,
each corresponding to an application class on the server and each commencing with
the keyword interface , followed by the name of the interface. (When the IDL is
compiled, each statement will generate a Java interface statement.) The body of
each interface declaration is enclosed by curly brackets and specifi es the data proper-
ties and the signatures of the operations (in CORBA terminology) that are to be made
accessible to clients. Each data property is declared with the following syntax:
attribute <type> <name>;
attribute long total;
By default, this attribute will be a 'read-and-write' attribute and will automati-
cally be mapped to a pair of Java accessor and mutator methods ('get' and 'set')
methods when the IDL fi le is compiled. For some strange reason, these methods do
not contain the words 'get' and 'set' or any equivalent verbs, but have the same
names as their (noun) attributes. [This is not good programming practice, at least as
far as the 'set' method is concerned!] The accessor and mutator methods for a given
attribute have exactly the same name, then, but are distinguished from each other by
having different signatures. The 'get' method takes no arguments and simply returns
the value of the attribute, while the 'set' method takes an argument of the corre-
sponding Java type and has a return type of void (though only the different argu-
ment lists are signifi cant for the compiler, of course). For the example above, the
accessor and mutator methods have the following signatures:
int total(); //Accessor.
void total(int i); //Mutator.
If we wish to make an attribute read-only (i.e., non-modifi able), then we can do
this by using the modifi er readonly . For example:
readonly attribute long total;
This time, only the accessor method will be created when the fi le is compiled.
The full set of basic types that may be used in attribute declarations is shown in
Table 6.1 , with the corresponding Java types alongside. The complete table can be
found at the following URL:
Within each operation signature, the basic types available for the return type are as
above, but with the addition of void . Types short , long and long long may
also be preceded by the qualifi er unsigned , but this will not affect the targets of
their mappings. The qualifi er const may also be used (though this generates an ini-
tialised variable in Java, rather than a constant indicated by the Java qualifi er fi nal ).
Parameters may have any of the basic types that data properties have, of course.
In addition to this, each parameter declaration commences with in (for an input
parameter), out (for an output parameter) or inout (for an update parameter).