Thou shalt support types or classes
This issue is touchy: there are two main categories of object-oriented
systems, those supporting the notion of class and those
supporting the notion of type. In the first category, are systems such
as Smalltalk [Goldberg and Robson 83], Gemstone [Maier, et al. 84], Vision [Caruso and Sciore 87], and more generally all the systems of
the Smalltalk family, Orion [Banerjee et al. 87], Flavors [Bobrow and Steifik 81], G-Base
[G-Base 88], Lore [Caseau 89] and more generally all
the systems derived from Lisp. In the second category, we find systems such
as C++ [Stroustrup 86], Simula [Simula 67], Trellis/Owl [Schaffert, et al. 86], Vbase
[Atwood 85] and O
[Bancilhon et al. 88].
A type, in an object-oriented system, summarizes the common features of a set of objects with the same characteristics. It corresponds to the notion of an abstract data type. It has two parts: the interface and the implementation (or implementations). Only the interface part is visible to the users of the type, the implementation of the object is seen only by the type designer. The interface consists of a list of operations together with their signatures (i.e., the type of the input parameters and the type of the result).
The type implementation consists of a data part and an operation part. In the data part, one describes the internal structure of the object's data. Depending on the power of the system, the structure of this data part can be more or less complex. The operation part consists of procedures which implement the operations of the interface part.
In programming languages, types are tools to increase programmer productivity, by insuring program correctness. By forcing the user to declare the types of the variables and expressions he/she manipulates, the system reasons about the correctness of programs based on this typing information. If the type system is designed carefully, the system can do the type checking at compile-time, otherwise some of it might have to be deferred at compile time. Thus types are mainly used at compile time to check the correctness of the programs. In general, in type-based systems, a type is not a first class citizen and has a special status and cannot be modified at run-time.
The notion of class is different from that of type. Its specification is the same as that of a type, but it is more of a run-time notion. It contains two aspects: an object factory and an object warehouse. The object factory can be used to create new objects, by performing the operation new on the class, or by cloning some prototype object representative of the class. The object warehouse means that attached to the class is its extension, i.e., the set of objects that are instances of the class. The user can manipulate the warehouse by applying operations on all elements of the class. Classes are not used for checking the correctness of a program but rather to create and manipulate objects. In most systems that employ the class mechanism, classes are first class citizens and, as such, can be manipulated at run-time, i.e., updated or passed as parameters. In most cases, while providing the system with increased flexibility and uniformity, this renders compile-time type checking impossible.
Of course, there are strong similarities between classes and types, the names have been used with both meanings and the differences can be subtle in some systems.
We do not feel that we should choose one of these two approaches and we consider the choice between the two should be left to the designer of the system (see Section 4.3). We require, however, that the system should offer some form of data structuring mechanism, be it classes or types. Thus the classical notion of database schema will be replaced by that of a set of classes or a set of types.
We do not, however, feel that is necessary for the system to automatically maintain the extent of a type (i.e., the set of objects of a given type in the database) or, if the extent of a type is maintained, for the system to make it accessible to the user. Consider, for example, the rectangle type, which can be used in many databases by multiple users. It does not make sense to talk about the set of all rectangles maintained by the system or to perform operations on them. We think it is more realistic to ask each user to maintain and manipulate its own set of rectangles. On the other hand, in the case of a type such as employee, it might be nice for the system to automatically maintain the employee extent.