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.