Java Reference
In-Depth Information
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>;
For example:
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).
Search WWH ::
Custom Search