Download An Introduction to IDL

CHAPTER 2. USING IDL: A TUTORIAL
6
a general characteristic of most IDL declarations; their order does not matter,
and you can dene several things in one declaration or split them into several
declarations.
Remember that we dened the item rep type as a pointer; similarly, date rep
would be a pointer. Thus, a.start date points to a date object that is separate from a. Thus, perhaps somewhat surprisingly, we have created a simple
graph, since item nodes point to date nodes; we will see in Section 3.2.2 how
to avoid this by embedding the dates in the items.
2.2.3 Classes
If we want to construct interesting graphs, we need a way to say that an
attribute can reference more than one type of node. The IDL way to do this
is to dene a strict class type. Thus
expression ::= binary | literal;
binary => left : expression, right : expression;
literal => symbol : string;
The rst line says expression is a strict class that contains classes binary and
literal. The left and right attributes of binary nodes form a graph by
pointing to other expression (that is, binary or literal) nodes.
At rst glance, strict classes seem similar to union types in languages such
as C or Algol-68. However, IDL classes give you more expressive power than
ordinary unions; they provide an inheritance mechanism similar to Simula
classes or Smalltalk objects. You can declare
expression => value : integer;
This says that all expression nodes have an integer-valued value attribute.
Thus every literal node or binary node will have such an attribute; they
inherit it from their parent, expression.
The term class includes both node types and strict class types. Thus
expression, binary, and literal are all classes, but only expression is a
strict class. We use this terminology to avoid having to say \strict class or
node type" in several places where we need to refer to both; we can say \class"
instead. Thus we can describe the two forms of denition we have seen so far
as \a class name, followed by =>, followed by a sequence of attribute denitions
separated by commas," and \a strict class name, followed by ::=, followed by
a sequence of class names separated by vertical bars."
Ideally, a target model will provide types and operations that match the
IDL graph's meaning as closely as possible. Thus you should be able to declare objects of implementation-language types corresponding to expression,
binary, and literal; you should also be able to fetch and store appropriate
attributes of each type. Thus after declaring