Subtyping And Other ISL Types

Subtyping and Other ISL Types

ILU ISL contains support for a number of types other than object types and REAL. The primitive ISL types include 16, 32, and 64 bit signed and unsigned integers, bytes, 8 and 16 bit characters, a boolean type, and 32, 64, and 128 bit floating point types.

A number of type constructors allow specification of arrays, sequences, records, unions, and enumerations, as well as object types. The ISL OPTIONAL type constructor provides an implicit union of some type with NULL, which is useful for building recursive data structures such as linked lists or binary trees.

To illustrate some of these types, we'll extend the Tutorial.Calculator type. Many real-world desktop calculators include a register tape, a printed listing of all the operations that have been performed, with a display of what the value of the calculator was after each operation. We'll add a register tape to Tutorial.Calculator.

We could do it by adding a new method to Tutorial.Calculator, called GetTape. Unfortunately, this would break our existing code, because it would change the Tutorial.Calculator object type, and existing compiled clients wouldn't be able to recognize the new object type. Instead, we'll extend the object type by subtyping; that is, by creating a new object type which uses Tutorial.Calculator as a supertype, but adds new methods of its own. This subtype will actually have two types; both its own new type, and Tutorial.Calculator. We'll also define a subtype of the Tutorial.Factory type, to allow us to create new instances of the new Calculator subtype. Finally, we'll define a new module interface for the new types, so that we don't have to modify the Tutorial interface.

First, let's define the necessary type to represent the operations performed on the calculator:

INTERFACE Tutorial2 IMPORTS Tutorial END;

TYPE OpType = ENUMERATION
    SetValue, Add, Subtract, Multiply, Divide END;

TYPE Operation = RECORD
    op : OpType,
    value : REAL,
    accumulator : REAL
  END;

TYPE RegisterTape = SEQUENCE OF Operation;

The enumerated type OpType defines an abstract type with five possible values. The type Operation defines a record type (in C, a struct) with 3 fields: the op field, which tells us which of the five possible calculator operations was performed, the value field, which tells us the value of the operand for the operation, and the accumulator field, which tells us what the value of the calculator was after the operation had been performed. Finally, the Operation type is a simple sequence, or list, of Operation. Note that Tutorial2 imports Tutorial; that is, it allows the use of the Tutorial types, exceptions, and constants, in the specifications in Tutorial2.

Now we define the new object types (in the same file):

TYPE TapeCalculator = OBJECT COLLECTIBLE
  SUPERTYPES Tutorial.Calculator END
  DOCUMENTATION "4 function calculator with register tape"
  METHODS
    GetTape () : RegisterTape
  END;

TYPE Factory = OBJECT SUPERTYPES Tutorial.Factory END
  METHODS
    CreateTapeCalculator () : TapeCalculator
  END;

The SUPERTYPES attribute of an object type may take multiple object type names, so ISL supports multiple inheritance. The Tutorial2.TapeCalculator type will now support the six methods of Tutorial.Calculator, as well as its own method, GetTape.

We then need to provide an implementation for Tutorial2. We use a data structure for the state of each calculator object:

struct calc_state {
  CORBA_double the_value;
  Tutorial2_RegisterTape *tape;
};

and modify each method on the TapeCalculator object to record its invocation.

We also provide an implementation for Tutorial2.Factory:

/* Factory2-impl.c */

/* Include the Tutorial header file, to get all the defined
 * types and function prototypes.
 */

#include <Tutorial2.h>

/* Code for the Factory object type */

extern Tutorial2_TapeCalculator Create_Tutorial2_TapeCalculator(void);

  Tutorial_Calculator
server_Tutorial2_Factory_CreateCalculator (
  Tutorial2_Factory f,
  CORBA_Environment *env)
{
  return ((Tutorial_Calculator) Create_Tutorial2_TapeCalculator());
}

  Tutorial2_TapeCalculator
server_Tutorial2_Factory_CreateTapeCalculator (
  Tutorial2_Factory f,
  CORBA_Environment *env)
{
  return (Create_Tutorial2_TapeCalculator());
}

Note that both the Tutorial2.Factory.CreateCalculator and Tutorial2.Factory.CreateTapeCalculator methods create and return instances of Tutorial2.TapeCalculator. This is valid, because instances of Tutorial2.TapeCalculator are also instances of Tutorial.Calculator.

Both `TapeCalculator-impl.o' and `Factory2-impl.o' are added to our library, along with the generated files from running c-stubber on `Tutorial2.isl':

% make
/usr/local/ilu/bin/c-stubber  Tutorial.isl
header file interface Tutorial to ./Tutorial.h...
common code for interface Tutorial to ./Tutorial-common.c...
code for surrogate stubs of interface Tutorial to ./Tutorial-surrogate.c...
code for true stubs of interface Tutorial to ./Tutorial-true.c...
rm -f Tutorial-common.o
cc -c -I. -I/usr/local/ilu/include Tutorial-common.c
rm -f Tutorial-surrogate.o
cc -c -I. -I/usr/local/ilu/include Tutorial-surrogate.c
rm -f Tutorial-true.o
cc -c -I. -I/usr/local/ilu/include Tutorial-true.c
/usr/local/ilu/bin/c-stubber  Tutorial2.isl
header file interface Tutorial2 to ./Tutorial2.h...
common code for interface Tutorial2 to ./Tutorial2-common.c...
code for surrogate stubs of interface Tutorial2 to ./Tutorial2-surrogate.c...
code for true stubs of interface Tutorial2 to ./Tutorial2-true.c...
rm -f Tutorial2-common.o
cc -c -I. -I/usr/local/ilu/include Tutorial2-common.c
rm -f Tutorial2-surrogate.o
cc -c -I. -I/usr/local/ilu/include Tutorial2-surrogate.c
rm -f Tutorial2-true.o
cc -c -I. -I/usr/local/ilu/include Tutorial2-true.c
rm -f Calculator-impl.o
cc -c -I. -I/usr/local/ilu/include Calculator-impl.c
rm -f TapeCalculator-impl.o
cc -c -I. -I/usr/local/ilu/include TapeCalculator-impl.c
rm -f Factory-impl.o
cc -c -I. -I/usr/local/ilu/include Factory-impl.c
rm -f Factory2-impl.o
cc -c -I. -I/usr/local/ilu/include Factory2-impl.c
rm -f libTutorial.a
ar clq libTutorial.a  Tutorial-true.o \
                      Tutorial-surrogate.o \
                      Tutorial-common.o \
                      Calculator-impl.o \
                      Factory-impl.o \
                      Tutorial2-true.o \
                      Tutorial2-surrogate.o \
                      Tutorial2-common.o \
                      TapeCalculator-impl.o \
                      Factory2-impl.o
ar: filename Tutorial-surrogate.o truncated to Tutorial-surrog
ar: filename Tutorial-common.o truncated to Tutorial-common
ar: filename Calculator-impl.o truncated to Calculator-impl
ar: filename Tutorial2-surrogate.o truncated to Tutorial2-surro
ar: filename Tutorial2-common.o truncated to Tutorial2-commo
ar: filename TapeCalculator-impl.o truncated to TapeCalculator-
ranlib libTutorial.a
% 

Now we modify `server.c' to create an instance of Tutorial2.Factory, instead of Tutorial.Factory, and to initialize the Tutorial2 true-side code

Note that one nice result of this approach to versioning is that old clients, which know nothing about the new TapeCalculator class, or about the whole Tutorial2 interface in general, will continue to function, since every instance of Tutorial2.TapeCalculator is also an instance of Tutorial.Calculator, and every instance of Tutorial2.Factory is also an instance of Tutorial.Factory.

Makefiles and Imakefiles

ILU includes support for a kind of macro-ized make system called called imake, that's distributed with the X Window System. With imake, most of the specific cruft of program options and switches is hidden behind macros. ILU provides some specific macros to do ILU-ish things, like running the c-stubber. To use imake, you put your rules in a file called `Imakefile', then run the program ilumkmf to create the real `Makefile'. Once you have the `Makefile', you can just use make.

An `Imakefile' for Tutorial and Tutorial2 would look like:

NormalObjectRule()
DependTarget()

InterfaceTarget(Tutorial.isl)
ILUCTarget(Tutorial.h Tutorial-true.c Tutorial-surrogate.c Tutorial-common.c, Tutorial.isl)
ObjectTarget(Tutorial-common.o)
ObjectTarget(Tutorial-surrogate.o)
ObjectTarget(Tutorial-true.o)

ObjectTarget(Calculator-impl.o)
Calculator-impl.o : Tutorial.h Calculator-impl.c

ObjectTarget(Factory-impl.o)
Factory-impl.o : Tutorial.h Factory-impl.c

InterfaceTarget(Tutorial2.isl)
ILUCTarget(Tutorial2.h Tutorial2-true.c Tutorial2-surrogate.c Tutorial2-common.c, Tutorial2.isl)
ObjectTarget(Tutorial2-common.o)
ObjectTarget(Tutorial2-surrogate.o)
ObjectTarget(Tutorial2-true.o)

ObjectTarget(TapeCalculator-impl.o)
TapeCalculator-impl.o : Tutorial.h Tutorial2.h TapeCalculator-impl.c

ObjectTarget(Factory2-impl.o)
Factory2-impl.o : Tutorial.h Factory2-impl.c

LibraryTarget (libTutorial.a, Tutorial-true.o Tutorial-surrogate.o Tutorial-common.o 
Calculator-impl.o Factory-impl.o Tutorial2-true.o Tutorial2-surrogate.o Tutorial2-common.o
TapeCalculator-impl.o Factory2-impl.o)

simple1.o : Tutorial.h simple1.c
ILUCProgramTarget(simple1, simple1.o, libTutorial.a,)

simple2.o : Tutorial.h simple2.c
ILUCProgramTarget(simple2, simple2.o, libTutorial.a,)

simple3.o : Tutorial.h simple2.c
ILUCProgramTarget(simple3, simple3.o, libTutorial.a,)

simple4.o : Tutorial.h simple4.c
ILUCProgramTarget(simple4, simple4.o, libTutorial.a,)

server.o : Tutorial.h server.c
ILUCProgramTarget(server, server.o, libTutorial.a,)

server2.o : Tutorial.h Tutorial2.h server2.c
ILUCProgramTarget(server2, server2.o, libTutorial.a,)

The two macros NormalObjectRule() and DependTarget() are required before the other macros. The macro InterfaceTarget() marks a file as being an ISL file. The macro ObjectTarget() specifies that the indicated object file should be produced. The macro ILUCTarget() indicates that running the c-stubber on the second argument will produce the first argument's files. The macro LibraryTarget() specifies that the library named by the first argument is composed of the object files named by the second argument. The macro ILUCProgramTarget() specifies the components necessary to build the image named by the first argument; the second argument lists all object files on which it is dependent, the third argument lists all libraries on which it is dependent, and the fourth lists all libraries and object files which it should be linked against, but which it is not dependent on.

Notice that normal make dependency rules can also be used in an `Imakefile'. The `Imakefile' is passed through the C preprocessor to expand the macros, so it is also possible to use features of cpp in the `Imakefile'.

Using OMG IDL with ILU

ILU also supports the use of the interface definition language OMG IDL, defined by the Object Management Group (OMG) for their Common Object Request Broker Architecture (CORBA). OMG IDL uses a C++-like syntax, so it may be easier for C and C++ programmers to use than ILU ISL. Unfortunately, CORBA doesn't include some of the concepts in ILU, such as garbage collection for transient objects, or OPTIONAL types, so not every ILU interface can be expressed in OMG IDL, but many of them can. For example, here is the OMG IDL version of the Tutorial interface:

module Tutorial {

  exception DivideByZero {};

  interface Calculator {
    // Set the value of the calculator to `v'
    void SetValue (in double v);
    // Return the value of the calculator
    double GetValue ();
    // Adds `v' to the calculator's value
    void Add (in double v);
    // Subtracts `v' from the calculator's value
    void Subtract (in double v);
    // Multiplies the calculator's value by `v'
    void Multiply (in double v);
    // Divides the calculator's value by `v'
    void Divide (in double v) raises (DivideByZero);
  };

  interface Factory {
    // Create and return an instance of a Calculator object
    Calculator CreateCalculator();
  };
};

This can be used with the c-stubber:

% c-stubber Tutorial.idl
header file for interface Tutorial to ./Tutorial.h...
common code for interface Tutorial to ./Tutorial-common.c...
code for surrogate stubs of interface Tutorial to ./Tutorial-surrogate.c...
code for true stubs of interface Tutorial to ./Tutorial-true.c...
% 

This will be a bit slower than running the c-stubber on the equivalent ISL file, as the program works by converting the OMG IDL into ISL, then compiling from the ISL description. OMG IDL interfaces can be checked by running the OMG IDL-to-ILU ISL converter, idl2isl, directly:

% idl2isl Tutorial.idl
INTERFACE Tutorial;

EXCEPTION DivideByZero;
TYPE Calculator = OBJECT OPTIONAL
        METHODS
                SetValue (v : REAL),
                GetValue () : REAL,
                Add (v : REAL),
                Subtract (v : REAL),
                Multiply (v : REAL),
                Divide (v : REAL)
                        RAISES DivideByZero END
        END;
TYPE Factory = OBJECT OPTIONAL
        METHODS
                CreateCalculator () : Calculator
        END;
% 

You will notice that the ISL interface generated by idl2isl is a bit different, in that the object type modifier OPTIONAL is used in the description of the Calculator and Factory types. This is because CORBA has the notion that any object type instance passed as a parameter or return value (or field in an array, or element of a sequence, etc.) may be NULL, instead of being a valid instance pointer. Thus, when working with OMG IDL descriptions of your interfaces, it is necessary to check the return type of methods like Tutorial.Factory.CreateCalculator to see that a valid object reference has been returned, before using the object. ISL allows you to have these CORBA-style objects, by using the OPTIONAL modifier in the declaration of an object type, but it also allows object pointers which can't be NULL. By default ILU object instances may not be NULL.