VOOPS' main purpose is to relieve a programmer from the work of coding object-oriented features manually, and to explicitly support them through specialized meta-language constructs in LISP via UNFUG, which implement those features using native host language C constructs. This approach is also used by some C++ compilers which behave like a sophisticated preprocessor and translate C++ code into C source code [Hewl90]. Although the intermediate C code can be output optionally, it is discarded by default and directly compiled to an object file with a native C compiler, thus effectively pretending the behavior of a C++ compiler.
To reflect the concept of classes and methods in C, some preconsiderations have to be made concerning the representation of classes, methods, and objects in C.
First of all, it has to be decided whether the class hierarchy should be static (i.e. defined and ``cast in concrete'' at compile time), or dynamic (i.e. extensible through new class and method definitions at run time). Since the PIF object model is defined in the PIF syntax and it is impossible that new PIF object classes could be necessary at run time, there is no need to strive for a dynamic class model, although there exist even public domain solutions for dynamic object-oriented programming extensions for C (e.g. the COOL library by L. NORSKOG). As we will see below, the static class model has the advantage that it can be implemented efficiently, thus allowing for a fast messaging concept.
When using a static class hierarchy, classes can be represented as C structures and methods as C functions in C header or source files, respectively. VOOPS uses UNFUG to evaluate special LISP expressions and insert the resulting string in place of the VOOPS statement into the C source code. Additionally, classes (and methods defined on them) are kept track of internally and stored in a save file at the end of a VOOPS run.
Classes and methods which belong together are grouped into a specific module which is referenced by a short mnemonic. All data structure, method, and macro names generated by VOOPS are prefixed with this module mnemonic to avoid possible naming conflicts within the VISTA system. This also enables the use of multiple class hierarchies in parallel without the danger of conflicting class and method definitions.
Figure 5.2: Inheritance in VOOPS