7. Types and Classes

OODBTG Reference Model

The object paradigm deals with both abstract, external behavior, andimplementation. Objects may be grouped into types by commonality of behavior(interface), and into classes by commonality of implementations⁷.

A "type" defines a protocol shared by a group of objects,called "instances" of the type. The type itself may be an object.

A "class" defines an implementation (methods and data structures)shared by a group of objects. A class may be considered an implementationof a type. There may be several classes (implementations) per type. Theclass itself may be an object; methods may also be objects.

The "signature" of an operation identifies the number andtypes of the operation's arguments and results. In classical object models,an operation is associated with the type of its recipient, and a methodis associated with the class of its recipient. In generalized models, anoperation is associated with the types of its parameters, and a methodis associated with the classes of its parameters. Thus, in generalizedmodels, operations and methods may be "jointly owned" by multipletypes and classes. In general, objects can have multiple types and classes,and these can change. Not all models permit this.

A "parameterized type" is the result of a compile-time operationthat takes classes as parameters and returns one or more derived classes,e.g., set<employee> might return "class set-employee,"the definition of a set class corresponding to a set of employee classinstances.

7 Within this section, the terms "type"and "class" are used prescriptively. While it is important todefine precisely the terms "type" and "class," almosteverywhere in this document except this section, the terms are used interchangeably.The term "class" is used uniformly in the rest of the documentbecause it is used in X3J13 Common Lisp (CLOS), X3J16 C++, and Smalltalk.Some programming languages like C++ define "type" to be a restrictedform of class without encapsulation, inheritance, and behavior and "class"to include these object concepts.

OMG Core Object Model

4.2.1 Basic Concepts
...

Objects are created as instances of types²(for example, integer, person, ship, stack).A type characterizes the behavior of its instances by describing the operationsthat can be applied to those objects. Types can be related to one anotherthrough supertype/subtype relationships. ...

2 Saying that an object is 'an instance of typeT' is the same as saying that an object is 'of type T' in this model.

4.2.3 Object Types

Objects support only certain operations. The operations applicable toan object collectively characterize its behavior. Types describe theseoperations and thus characterize the behavior of objects. Objects are createdas instances of their types and in the Core Object Model objects do notchange their type.

Each operation has a signature, which consists of a name, set of parameters⁴,and set of results (see section 4.2.5). The set of operation signaturesdefined on a type is called the type's interface. A type's interfaceincludes signatures that are inherited from supertypes (see section 4.2.6).Every instance of a type satisfies the interface of that type.

Types are arranged into a type hierarchy that forms a directed acyclicgraph. The root of this type hierarchy is the type Object. Applicationsintroduce new types by subtyping from Object. Having a single root allowsprograms to specify that an argument can take an object of any type. Theset of all object types is referred to as OTypes.

A type is distinct from its interface and its set of instances (extension).Both its interface and extension can change over time, without changingthe identity of the type. Although the Core defines types and operationsas concepts, systems that comply to the model need not provide objectsthat correspond to these concepts. Types and operations as objects willbe considered for inclusion in the Meta_data component of the OMG OM ComponentsGuide.

Editor's note: the OMG OM Components Guide exists in draft form only.

4 In the Core Model, the term parameteris used when referring to the declaration of an operation's interface.Argument is used when referring to an operation invocation.

4.2.9 Implementation

As noted earlier, the Object Model formally specifies only the semanticsof objects. It has nothing to say about their implementation. It neitherrequires nor excludes systems in which there is more than one implementationfor a given type. It permits systems in which each object type has a separateimplementation, or in which clusters of related types share an implementation.

The combination of a type specification and one of the implementationsdefined for that type is termed a class. An individual object, atany given point in time, is an instance of one class. The model makes nostatement about whether an object must retain the implementation chosenfor it at the time it was created or whether an object can change implementationsover its lifetime. Moreover, implementations may vary among different instancesof a type, and even for the same instance over time.

Allowing multiple implementations for a given type specification seemsnecessary to support several domains including databases that span networksthat include machines with different architectures, and mixed-languageenvironments. But even in a single- machine, single-language environmentthere are cases where the programmer wants to have available differentimplementations of a type based on different data structures or algorithms.In the absence of multiple implementations for a single type, the typeprogrammer would be forced to abuse the subtype mechanism to achieve thisdifferentiation; for instance, by defining a distinct subtype for eachdistinct implementation of a type. Set_as_Btree and Set_as_Linked_Listwould be introduced, for example, as subtypes of the type Set,rather than as alternate implementations for the type Set.

OMG CORBA IDL

A type is an identifiable entity with an associated predicate definedover values. A value satisfies a type if the predicate is true for thattype. A value that satisfies a type is called a member of the type. Theextension of a type is the set of values that satisfy the type at any particulartime [CORBA Specification 2.2.4 Types].

Types are used in signatures to restrict a possible parameter or tocharacterize a possible result. An object type is a type whose membersare objects. Basic data types are 16 and 32 bit signed and unsigned 2'scomplement integers, 32 bit and 64 bit IEEE floating point numbers, charactersas defined in ISO Latin-1 (8859.1), a boolean type taking the values TRUEand FALSE, and 8-bit opaque data type, guaranteed to not undergo any conversionduring transfer between systems, enumerated types consisting of orderedsequence of identifiers, a string type which consists of a variable-lengtharray of characters, a type any which can represent any possible basicor constructed type [CORBA Specification 2.2.4 Types].

Constructed types consist of a record type(called struct), consistingof an ordered set of (name, value) pairs, a discriminated union type consistingof a discriminator followed by an instance of a type appropriate to thediscriminator value, a sequence type which consists of a variable-lengtharray of a single type, an array type which consists of a fixed-lengtharray of a single type, and an interface type which specifies the set ofoperations, which an instance of that type must support [CORBA Specification2.2.4 Types].

ODMG

A type is a specification; it can have one or more implementations.All types are instances of type Type. A class is the combination of a typespecification and a specific implementation. The model is strongly typed.

The set of all instances of a type is the 'extent' of the type. 'Abstracttypes' are not instantiable - they specify characteristics that can beinherited by subtypes but do not define any implementations.

Two objects are compatible if they are instances of the same declaredtype or if one is an instance of a subtype of the other. Two structuredliterals have the same type if they have the same structure at every leveland the corresponding atomic types are the same. Subtyping for structuredliterals requires the same structure at each level and the type of eachsubobject of the subtype to be the same as, or a supertype of, the correspondingsubobject of the supertype. No implicit conversions are given for eitherobjects or structured literals. Some explicit conversions are given inthe object query language specification.

EXPRESS

The fundamental constructs of EXPRESS are entities and types. Whileboth are considered to be types, entities differ from the other types inthree respects: 1) a subtype/supertype relation is defined only on entitytypes, 2) entity instances have identifiers while others do not, and 3)entity instances can have a significantly more complex internal structure.The types in EXPRESS include the usual primitive types (integer, string,etc.) as well as enumeration, aggregation, and select (union) types. User-definedtypes are also supported, and can be founded on any types other than entities.

An entity type is defined by a set of attributes. An attribute has anassociated value (or none) for each instance of the entity type.

EXPRESS does not require the subtypes of a particular supertype to bedisjoint; thus, it is possible for and instance of the supertype to bean instance of two or more subtypes simultaneously. The language allowsthe ways in which the subtypes may overlap to be constrained using theso-called supertype expression. For example, it is possible to state that"these two subtypes are disjoint" or that "an instance ofthe supertype must be an instance of at least one of these three subtypes,and also of no more than one of these four subtypes".

Open Distributed Processing

A fundamental notion of ODP, used extensively.

A type is defined by a set of conditions and constraints, known as apredicate. An object instance is said to be of a particular type if itsatisfies the predicate. A type therefore identifies a collection of objectinstances (i.e., the instances that satisfy the predicate). Conversely,every arbitrary collection of object instances defines a type.

Strengthening a predicate (i.e., adding further conditions), definesa subtype. Under these circumstances the original (weaker) predicate issaid to define a supertype. Any object instance satisfying the subtypepredicate will also, by definition, satisfy the supertype predicate. Ifa type is thought of as identifying a set of instances, then a subtypeidentifies a subset of those instances. Each of subtype may in turn beused to generate further subtypes. Therefore, the subtyping relationshipdefines a type hierarchy.

It is necessary to describe the information associated with modelingconcepts, irrespective of the actual specification language. This is accomplishedthrough a template or a "form'' which supplies a syntactic frameworkto present the information employing these concepts.

Among the many possible groupings of object instances, some will beof greater interest than others. ODP allows these interesting collectionsof objects to be explicitly identified and named, through the use of templatetypes. A template type is a particular example of a type, carefully chosenby the specifier to identify a specific group of objects known as a class.The template type defines the type of each object instance belonging tothe class.

To provide a completely general model of classes, a template type ismodeled as a template and associated instantiation rules. The templatespecifies the common features of the object instances belonging to theclass, while the instantiation rules specify how to generate instancesfrom the template. Together they specify the template type. Note that,in practice, the instantiation rules will normally be fixed for a giventemplate specification language in a given environment. Under these circumstances,template type becomes synonymous with class template.

A subclass is defined by incrementally modifying the class template.The class, corresponding to the original template, is termed the superclass.Instances of the subclass do not necessarily form a subset of instancesof the superclass. That is, a subclass does not necessarily form a subsetof instances of the superclass and a subclass does not necessarily definea subtype. This depends upon the nature of permissible incremental modifications.If the class predicate can only be strengthened by incremental modificationsto the class template, then the type of a subclass will correspond to asubtype of the superclass' type. If, however, the predicate can be arbitrarilymodified, then this relationship will not necessarily hold.

In the same manner as types, classes can be arranged in a class hierarchyaccording to the superclass-subclass relationship.

Management Information Model

Each managed object is an instance of a class that includes all managedobjects that share the same definition. A distinguished name is used toname each managed object unambiguously...The definition of a managed objectclass ... consists of:

- The position of the managed object class in the inheritance hierarchy.

- A collection of mandatory packages of attributes, operations, notifications,and behavior.

- A collection of conditional packages of attributes, operations, notifications,and behavior, together with the condition under which each package willbe present. [Part 1]

One managed object class is specialized from another managed objectclass by defining it as an extension of the other managed object class.Such an extension is made by defining further packages that include oneor more of the following:

-new management operations
-new attributes
-new notifications
-new behavior
-extensions to the characteristics of the original managed object class.

A managed object class that is specialized from another managed objectclass is known as a subclass of that class (its superclass). One managedobject class, called top, is designated as the ultimate superclass in theclass hierarchy. Top is an uninstantiable managed object class. [Part 1]

A managed object class defines the characteristics of a typeof physical or logical resource. Instances of a managed object class existto represent specific instances of a resource. Therefore, a managed objectis an instance of a managed object class. The terms "object"and "object instance" are synonymous.

A managed object class is characterized by one or more packages. A packageis a collection of properties of that managed object class. Each consistsof behavior definitions, attributes, attribute groups, actions, and notifications.When a managed object class definition includes a package, a managed objectof that class exhibits all the characteristics stated in the package. Additionally,a package included in a managed object class definition may be mandatoryor conditional.

If the same characteristic, e.g., attribute, is present in two or morepackages of the same managed object class definition, only one copy ofthe characteristic may be present in an instance of that class.

A managed object class may be compatible with another managedobject by having the same characteristics as that other managed objectclass (the compatible class), and optionally extended characteristics.The compatible class may be one of the superclasses of that managed object'sclass in the inheritance hierarchy; however, this is not a requirement.The extended managed object must include all of the mandatory characteristics(i.e., attributes, attribute groups, management operations, and notifications)that would be present in an instance of the compatible managed object class;however the mandatory packages of the extended managed object do not haveto be related to the mandatory packages of the compatible class. Additionalrules of compatibility are found in [ISO/IEC 10165-1, MIM].

SQL3

The parts of SQL3 that provide the primary basis for supporting object-orientedstructures are extensions to its type facilities, specifically:

user-defined types (ADTs, named row types, anddistinct types)
type constructors for row types and reference types
type constructors for collection types (sets, lists, and multisets)
user-defined functions and procedures
support for large objects (BLOBs and CLOBs)

SQL3 also supports a number of built-in scalar types.

One of the basic ideas behind the object facilities is that, in additionto the normal built-in types defined by SQL, user-defined types may alsobe defined. These types may be used in the same way as built-in types.For example, columns in relational tables may be defined as taking valuesof user-defined types, as well as built-in types.

The simplest form of user-defined type in SQL3 is the distincttype, which provides a facility for the user to declare that two otherwiseequivalent type declarations are to be treated as separate data types.The keyword DISTINCT used in an declarationindicates that the resulting type is to be treated as "distinct"from any other declaration of the same type. For example, if two new typesare declared as:

CREATE DISTINCT TYPE us_dollar ASDECIMAL(9,2)

CREATE DISTINCT TYPE canadian_dollarAS DECIMAL(9,2)

any attempt to treat an instance of one type as an instance of the otherwould result in an error, even though each type has the same representation.

A user-defined abstract data type (ADT) definition encapsulatesattributes and operations in a single entity. In SQL3, an abstract datatype (ADT) is defined by specifying a set of declarations of the storedattributes that represent the value of the ADT, the operations that definethe equality and ordering relationships of the ADT, and the operationsthat define the behavior (and any virtual attributes) of the ADT. Operationsare implemented by procedures called routines. ADTs can also bedefined as subtypes of other ADTs. A subtype inherits the structure andbehavior of its supertypes (multiple inheritance is supported). Instancesof ADTs can be persistently stored in the database only by storing themin columns of tables. An example ADT declaration from [Mat95] is:

CREATE TYPE employee_t  (PUBLIC    name CHAR(20),    b_address address_t,    manager employee_t,    hiredate DATE,

  PRIVATE    base_salary DECIMAL(7,2),    commission DECIMAL(7,2),

  PUBLIC    FUNCTION working_years (p employee_t) RETURNS INTEGER     <code to calculate number of working years>,

  PUBLIC    FUNCTION working_years (p employee_t, y years) RETURNS employee_t     <code to update number of working years>,

  PUBLIC    FUNCTION salary (p, employee_t) RETURNS DECIMAL     <code to calculate salary> );

ADTs are completely encapsulated; only attributes and functions definedas PUBLIC are accessible from outside the ADT definition. For each attribute(such as name), an observerand mutator function is automatically defined. Virtual attributes (suchas working_years) canalso be defined. These do not have stored values; their behavior is providedby user-defined observer and mutator functions that read and define theirvalues (salary is a read-onlyvirtual attribute). ADT instances are created by system-defined constructorfunctions. The instances created in this way have their attributes initializedwith their default values, and can be further initialized by the user byinvoking mutator functions, as in:

BEGIN   DECLARE e employee_t;   SET e..working_years = 10;   SET y = e..working_years;   SET z = e..salary; END;

The expression e..working_yearsillustrates the dot notation used to invoke the working_yearsfunction of the ADT instance denoted by e.Users can also define specialized constructor functions which take parametersto initialize attributes.

A row type is a sequence of field name/data type pairs resemblinga table definition. Two rows are type-equivalent if both have the samenumber of fields and every pair of fields in the same position have compatibletypes. The row type provides a data type that can represent the types ofrows in tables, so that complete rows can be stored in variables, passedas arguments to routines, and returned as return values from function invocations.This facility also allows columns in tables to contain row values. An exampleis:

CREATE TABLE employees    (name CHAR(40),     address ROW(street CHAR(30),                 city CHAR(20),                 zip ROW(original CHAR(5),                         plus4 CHAR(4))));

INSERT INTO employees VALUES('John Doe', ('2225 Coral Drive', 'San Jose', ('95124', '2347'))));A named row type is a row type with a name assigned to it. A named row type is effectively a user-defined data type with a non-encapsulated internal structure (consisting of its fields). A named row type can be used to specify the types of rows in table definitions. For example:

CREATE ROW TYPE account_t   (acctno INT,    cust REF(customer_t),    type CHAR(1),    opened DATE,    rate DOUBLE PRECISION,    balance DOUBLE PRECISION,   );

CREATE TABLE account OF account_t   (PRIMARY KEY acctno   );

A named row type can also be used to define a reference type.A value of the reference type defined for a specific row type is a uniquevalue which identifies a specific instance of the row type within somebase (top level) database table. A reference type value can be stored inone table and used as a direct reference ("pointer") to a specificrow in another table, just as an object identifier in other object modelsallows one object to directly reference another object. The same referencetype value can be stored in multiple rows, thus allowing the referencedrow to be "shared" by those rows. For example, the account_trow type defined above contains a custcolumn with the reference type REF(customer_t).A value of this column identifies a specific row of type customer_t.The value of a reference type is unique within the database, never changesas long as the corresponding row exists in the database, and is never reused.

In general, the value of a reference type such as REF(customer_t)can refer to a row in any table having rows of type customer_t.If a SCOPE clause is specified in the definition of a table, such referencesare restricted to rows in a single table, as in:

CREATE TABLE account OF account_t   (PRIMARY KEY acctno,    SCOPE FOR cust IS customer   );

In this case customer_trows referenced in the custcolumn must be stored in the customertable. Use of SCOPE does not imply any referential integrity constraint.

References can be used in path expressions (similar to thoseused in some other object query languages), that permit traversal of objectreferences to "navigate" from one row to another. Such expressionscan also include the invocation of functions on ADT instances. An exampleis:

SELECT a.cust->name   FROM account a   WHERE a.cust->address..city = "Hollywood"   AND a.balance > 1000000;

In the SELECT statement, a.cust->namerepresents:

1. the selection of the custcolumn's value (an instance of type REF(customer_t)) from the row denoted by a(a row of type account_t)

2. the traversal (dereference) of that instance of type REF(customer_t)to the row of type customer_tit refers to (-> isa dereferencing operator)

3. the selection of the name column from the referenced customer_trow.

In the WHERE clause,a.cust->address..cityrepresents a similar process, identifying the addresscolumn of the referenced customer_trow, and then applying the cityobserver function to the ADT instance found in the addresscolumn.

Collection types for sets, lists, and multisets have also beendefined. Using these types, columns of tables can contain sets, lists,or multisets, in addition to individual values. For example:

CREATE TABLE employees    (id INTEGER PRIMARY KEY,     name VARCHAR(30),     address ROW(street VARCHAR(40),                 city CHAR(20),                 start CHAR(2),                 zip INTEGER),                 projects SET (INTEGER),                 children LIST(person),                 hobbies SET (VARCHAR(20))    );

The BLOB (Binary Large Object) and CLOB (Character Large Object) typeshave been defined to support very large objects. Instances of these typesare stored directly in the database (rather than being maintained in externalfiles). For example:

CREATE TABLE employees    (id INTEGER,     name VARCHAR(30),     salary us_dollar, ...     resume CLOB(75K),     signature BLOB(1M),     picture BLOB(12M));

LOB types are excluded from some operations, such as greater and lessthan operators, but are supported by other operations, such as value retrieval,and the LIKE predicate.

Matisse

In Matisse, as in many object systems, a class is an implementationof a type. Attributes are typed as in C or C++.

Classes, including the metaclass and its associated objects are "firstclass objects" in Matisse. They are physically stored as objects onthe server and may be modified like any other object. This allows supportof on-line schema evolution.

The structure and function of objects is determined by the metaclass.The user may modify the metaclass to support specialized data models andfunctionality. For example, the metaclass Attribute can be modified toallow read and write to data in an external relational database. This allowsany attribute of any object in the system to be specified as residing inan external database. When an object is accessed, such attributes appearas part of the object transparently to the user.

C++

In C++, an object is a region of storage with associated semantics.The declaration int i;, specifies that iis an object of type int. In the context ofthe object model of C++, the term object refers to an instance ofa class. Thus a class defines the behavior of possibly many objects (instances).Objects are usually referred to by references, which are aliasesfor an object.

A C++ class definition generates a user-defined type. A class definesthe characteristics of its instances in terms of members: data members(state) and member functions (methods or operations), and the visibilityof these members to other classes. The class defines the form of all objectsthat belong to that class. Each object of the class that is created getsa copy of all the class data members, except for those declared as static.All objects of a particular class share the member functions for that class.If a class data member is defined with the statickeyword, that data member is shared by all objects of that class (thereis only one copy of the static data member).

C++ is a statically-typed language (although it supports explicit castsand unions that allow type checking to be suspended). A class essentiallydefines a type, and a derived class (subclass) is effectively a subtype.If a variable is of a type A, then it may only refer to objects of classA or its derived classes (subclasses). When a subclass is declared, thosemembers which redefine members declared in a superclass must be declaredin a way that is consistent with the superclass declaration, in order tomaintain substitutability of subclass instances.

An example rectangle class definition [Wes90] is:

class TRect { public:    // data members    short fTop;    short fLeft;    short fBottom;    short fRight;    // member functions    short Area(void);    Boolean PointInRect(Point thePt); };

A class can be declared within another class; such a class is calleda nested class. The name of a nested class is local to its enclosingclass. A class can also be declared within a function definition; sucha class is called a local class. The name of a local class is localto its enclosing scope.

An abstract class is a class that can be used only as a baseclass of some other class; no objects of an abstract class can be createdexcept as objects representing a base class of a class derived from it.Abstract classes support the notion of a general concept, such as shape,of which only more concrete variants, such as circleand square, can actuallybe used. An abstract class can also be used to define an interface forwhich derived classes provide a variety of implementations [Str92].

A class is abstract if it has at least one pure virtual function.Specifying a function in a base class as virtualmeans that if a derived class contains a function with the same name andhaving the same type, a call of that function for an object of the derivedclass always invokes the function in the derived class, even though theinvocation was through a pointer or reference to the base class. In thiscase, the derived class function is said to override the base classfunction. A virtual function is specified pure by specifying itsimplementation as =0 inthe function declaration in the class declaration.

C++ class templates provide a parameterized type facility (genericity).A class template specifies how individual classes can be constructed. Forexample, an example vector class template [Str92] might be:

template<class T> class vector {    T* v;    int sz; public:    vector (int);    T& operator[] (int);    T& elem(int i) { return v[i]; }    // ... };

The prefix template<class T>specifies that a template is being declared and that a type name Twill be used in the declaration (i.e., that vector is a parameterized typewith T as its parameter).A class generated from a class template is called a template class.Examples might be vector<int>,vector<complex>,etc. Such names can be used in the same way as the names of ordinary classes.

OOCOBOL

Any object in OO COBOL belongs to a class. A class describes the structureof the data and the methods that apply to all the objects belonging tothat class. A class also has a single class object with data and methods.The class object is an object that acts as a creator of objects. Each classdefines two interfaces: an interface defining the methods supported bythe class object (the class object interface), and the interface to besupported by each instance of the class. The structure of a class definitionis given below.

IDENTIFICATION DIVISION.                           { TRANSIENT [COLLECTABLE] } CLASS-ID. class-name-1 IS {                         }                           { PERSISTENT              }      [INHERITS {class-name-2}...]. [Class Environment Division] [IDENTIFICATION DIVISION. CLASS-OBJECT. [Class Object Environment Division] [Class Object Data Division] [PROCEDURE DIVISION. [{Class Methods}...]] END CLASS-OBJECT.] [IDENTIFICATION DIVISION. OBJECT. Object Environment Division] [Object Data Division] [PROCEDURE DIVISION. [{Object Methods}...]] END OBJECT.] END CLASS.

Interfaces independent of class objects or class instances may be definedby listing the method names and parameter specifications supported by thoseinterfaces. Such an interface may be specified in the declaration of anobject identifier to restrict the objects that may be referred to by thatidentifier to objects whose interfaces conform to the specified interface.Conformance is a relationship between interfaces. One interfaceis said to conform to a second interface if an object that implements allthe methods specified in the first interface may be used anywhere an objectthat implements all the methods specified in the second interface may beused. A formal definition for conformance is included in the specifications[Obi94].

OO COBOL defines a built-in class called CBL-BASE that user-definedclasses can inherit from. This class provides essential functionality forcreation and management of objects. [Obi94] describes a minimal implementationof the CBL-BASE class, which is given below. The actual definition of theCBL-BASE class is implementor defined, but should provide the same or greaterfunctionality. Implementors may define data and other methods for the classobject interface, the object interface, or both.

CLASS-ID. CBL-BASE. CLASS-OBJECT PROCEDURE DIVISION. cbl-create-method cbl-new-method END CLASS-OBJECT. OBJECT. PROCEDURE DIVISION. cbl-class-method cbl-discard-method cbl-initialize-method cbl-iscollectable-method cbl-isperistent-method END OBJECT. END CLASS CBL-BASE.

The following are examples of the definitions of some of these methods.They illustrate some of the basic functionality of OO COBOL classes, andalso some of the syntax of method definition in OO COBOL.

The CBL-CREATE method is a class method that allocates storage for anobject and initializes its object data to the values specified in VALUEclauses. The method requires system services, and thus only a skeletoncan be specified in OO COBOL.

METHOD-ID. CBL-CREATE IS RESTRICTED. DATA DIVISION. LINKAGE SECTION. 01 CREATED-OBJECT USAGE OBJECT REFERENCE SELF. PROCEDURE DIVISION RETURNING CREATED-OBJECT.    ...    EXIT METHOD. END METHOD CBL-CREATE.

The CBL-NEW method is a class method that is used to create objectsof a class. It makes use of the CBL-CREATE method, and can be written inOO COBOL.

METHOD-ID. CBL-NEW. DATA DIVISION. LINKAGE SECTION. 01 CREATED-OBJECT USAGE OBJECT REFERENCE SELF. PROCEDURE DIVISION RETURNING CREATED-OBJECT.    INVOKE SELF "CBL-CREATE" RETURNING CREATED-OBJECT    INVOKE CREATED-OBJECT "CBL-INITIALIZE" EXIT METHOD. END METHOD CBL-NEW.

The CBL-ISPERSISTENT method returns an indicator as to whether thisobject is persistent. Only a skeleton can be written in OO COBOL.

METHOD-ID. CBL-ISPERSISTENT. DATA DIVISION. LINKAGE SECTION. 01 RESULT PIC X.   88 IS-TRUE VALUE "Y".   88 IS-FALSE VALUE "N". PROCEDURE DIVISION RETURNING RESULT. ...   EXIT METHOD. END METHOD CBL-ISPERSISTENT.

Smalltalk

Smalltalk does not have a separate notion of "type" (messageprotocol shared by a group of objects) apart from "class."

A class is a group of objects that represent the same type of entityand share the same methods. A class describes the implementation of a setof similar objects. Classes are themselves objects. All objects belongto some class and an object is an instance of the class of which it belongs.

Eiffel

Every object is a direct instance of exactly one type. It may also beindirectly an instance of more than one type through inheritance.

An Eiffel program (text) describes possible types through their stateand operations.

Typing in Eiffel is static. i.e., every component denoting run-timevalues is typed and the type of the component is determined by its declarationin a class text.

There are three possible kinds of types: reference type, expanded typeand formal_generic_type. The first two denote possible run-time componentsthat either reference an object or are and actual object, respectively.

Formal_generic_types represent generic parameters to be provided inactual used of the class by parents or proper descendants. See also entryunder 9.5 aggregates.

Every class is a type.

Emerald

Emerald's type system reflects its intended use in the development ofsoftware in constantly running distributed systems. In such systems, objectsmay be developed and implemented separately and differently on differentmachines at different times. Moreover, to accommodate situations wherethe types of the objects to be bound to an identifier are not known atcompile time, the Emerald type system does not distinguish between objectsbased on their implementation.

An Emerald abstract type is a collection of operation signatures,where a signature consists of the operation name and the types of the operation'sarguments and results. A type contains no information about implementation;it only describes an interface. An example of a simple type declarationis:

const Printable <-     type Printable       function asString -> [String]   end Printable

Each identifier in an Emerald program, including the names of constants,variables, arguments, and results, has a declared type, which must be evaluableat compile time; this is called the syntactic type of the name.For example, using the above type declaration, one might define a variablevar aPrintableObj: Printable.Type checking in Emerald is the process of ensuring that the object towhich a name is bound always satisfies the syntactic type of the name.The precise definition of "satisfies" in this context is givenby the conformity relation. If an object O is bound to a name I,then the abstract type of O must conform to the syntactic type ofI.

The motivation behind Emerald's definition of conformity is the notionof substitutability. Informally, an abstract type S conforms to an abstracttype T (written S o> T) if an object of type S can always be substitutedfor one of type T, that is, the object of type S can always be used whereone of type T is expected. For S to be substitutable for T in this wayrequires that

1. S provides at least the operations of T (S may have more operations)

2. For each operation in T, the corresponding operation in S has thesame number of arguments and results.

3. The types of the results of S's operations conform to the types ofthe results of T's operations.

4. The types of the arguments of T's operations conform to the typesof the arguments of S's operations. (Note the reversal in the order ofconformity for arguments).

Property 4 is known as contravariance (property 3 is known ascovariance). The idea behind contravariance is that an operationon objects of a given type should also work on objects of subtypes of thattype.

Each Emerald object may belong to several abstract types because anobject O belongs to an abstract type T when typeofO o> T. The application of typeofto an object returns its maximal type, that is, the largest Emeraldtype that the object can belong to. [RTLB+91]

Emerald's approach to typing allows the use of any object that can handlea given set of messages (satisfies an interface) in a context that sendsjust those messages (requires that interface), independently of how thosemessages are implemented within the object. It also allows both the requirementsof clients and the capabilities of objects to be expressed abstractly,in terms (respectively) of the required and provided interfaces, withoutbeing bound to specific combinations of operations that object implementorshave chosen to implement, or that are defined in existing type specifications.Moreover, it permits these advantages to be obtained while retaining theability to perform strong type-checking.

The conventional approach to defining subtype relationships among typesis to explicitly declare them. However, the conformity relation used inEmerald instead creates implicit subtype relationships among definedtypes, and, in fact, induces a lattice on those types (the top of thislattice is the predefined type Any,which has no operations). Any type that supplies the interface requiredby type T is implicitly a subtype of T, and may be used as such. Thus,conformity allows the introduction of new supertypes into a type latticewithout having to modify the definitions of existing types (or the structureof the type lattice). Emerald provides no means for explicitly declaringthe conformity relation (e.g., for explicitly declaring that one abstracttype is a subtype of another). Instead, this is determined by comparingthe operation signatures defined for the types. This can lead to "mistaken"type matches when two types that are not semantically related happen tohave the same operation signatures. Such problems can be reduced by includingoperations in the types that are specific to the type defined.

Emerald has no notion of class; Emerald provides object constructorsfor run-time creation of objects. An object constructor is an Emerald expressionthat, when evaluated, creates a new object. Object constructors performthe following subset of the functions carried out by classes in a languagesuch as Smalltalk:

1. They generate new objects.

2. They describe the representation of objects.

3. They define the code that implements operations. [RTLB+91]

A number of similar objects can be created by placing an object constructorwithin a loop, or within the body of an operation of another object. Thisallows for the definition of "factory objects" if that is desired.

The Emerald compiler generates templates that describe the structureof each object. Code and templates are stored in kernel structures calledconcrete types. One concrete type exists for each object constructor.Concrete types are immutable, and copies of them may exist on many nodes.When an object is moved to another node, the concrete type is not sentalong; it is requested by the target node only if needed. Concrete typessupport the sharing of structure information and operation code among objectsconstructed using the same object constructor. As a result, to a certainextent concrete types resemble classes from an implementation point ofview. However, concrete types are apparently not visible at the Emeraldlanguage level, but are instead considered part of the language implementation.

Locating the code for an invoked operation is simplified by the Emeraldtype system. The abstract type of a variable specifies the operations thatcan be performed on the object it names. At run time, the variable referencesan object with a specific concrete type. Even though the object may havemore operations than the abstract type, the additional operations cannotbe invoked.

The data structure used to locate operations is called an Abstract-Concretevector. Each variable has associated with it a vector with one entry foreach operation defined by its abstract type. The contents of the entryis the address of the corresponding procedure entry point in the concretetype. When an assignment is made, the vector may have to be changed ifthe new object is implemented by a different concrete type. The compilergenerates code to perform this change if it cannot tell the concrete typeof the object to be assigned. [BHJL86]

Cecil

Cecil supports a static type system which is layered on top of a dynamically-typedcore language. Cecil's type system is descriptive rather than prescriptive.The semantics of a Cecil program are determined completely by the dynamically-typedcore of the program. Type declarations serve only as documentation andpartial redundancy checks, and they do not influence the execution behaviorof programs. It is intended that type annotations could be added to a programas it progresses from development to production use.

A type in Cecil is an abstraction of an object. A type representsa machine-checkable interface and an implied but unchecked behavioral specification,and all objects which conform to the type must support the type'sinterface and promise to satisfy the behavioral specification. One typemay claim to be a subtype of another, in which case all objectswhich conform to the subtype are guaranteed also to conform to the supertype.The type checker verifies that the interface of the subtype conforms tothe interface of the supertype, but the system must accept the programmer'spromise that the subtype satisfies the implied behavioral specificationof the supertype. Subtyping is explicit in Cecil just so that these impliedbehavioral specifications can be indicated.

A signature in Cecil is an abstraction of a method, specifyingboth an interface (a name, a sequence of argument types, and a result type)and an implied but uncheckable behavioral specification. A set of signaturesforms the interface of a type. A signature is viewed as associated witheach of its argument types, not just the first, much as a multi-methodin Cecil is associated with each of its argument specializers.

Cecil separates subtyping from code inheritance. However, since in mostcases the subtyping graphs and the inheritance graphs are parallel, inCecil both graphs are specified simultaneously with a single set of objectand method declarations. An object declaration constructsboth a new object in the inheritance graph and a new type in the type lattice(similarly, a method implies the existence of a corresponding signature).See entry under 2.6 object lifetime. The new object in the inheritance(implementation) graph is a direct child of the objects named in the inheritsand isa clauses, if any.The new node in the type lattice is a direct subtype of each of the typesnamed in the subtypesand isa clauses, if any.Finally, the new object is declared to conform to the new type. Objectconstructor expressions similarly generate both objects and types, butthese objects and types are anonymous (have no names).

Each of the names included in an isaclause is interpreted both as an object (when constructing the inheritancegraph) and as a type (when constructing the type lattice), and so providesa shorthand for declaring both inheritsand subtypes clauses withthe same name. This is designed to make it easy to specify the inheritanceand subtyping properties of an object/type pair for the common case wherecode inheritance and subtyping are parallel. It is expected that in mostprograms only isa declarationswill be used; inheritsand subtypes declarationsare intended for the cases where distinctions between inheritance and subtypingmust be specified.

Some objects are not intended to correspond to first-class types used,e.g., in variable declarations. To support this distinction, an objectdeclaration that is intended to generate a first-class namable type usesthe keyword type ratherthan object in the objectdeclaration. Both objectand type declarationscreate both an object and a type, but the type created as part of an objectdeclaration is an internal type that cannot normally be named by the program.

At present, Cecil does not provide programmers the ability to definetypes or signatures separately from objects and methods. If only a typeor signature is needed, then an abstracttype object declaration or an abstractmethod can be used.

Subtyping and conformance in Cecil is explicit, in that the programmermust explicitly declare that an object conforms to a type and that a typeis a subtype of another type. These explicit declarations are verifiedas part of type checking to ensure that they preserve the required propertiesof conformance and subtyping. Explicit declarations are used in Cecil insteadof implicit inference of the subtyping relations (structural subtyping,or conformity as in Emerald) both to provide programmers with error-checkingof their assumptions about what objects conform to what types and whattypes are subtypes of what other types, and to allow programmers to encodeadditional semantic information in the use of a particular type name inaddition to the information implied by the type's method signatures.

SELF

Like Smalltalk, SELF has no type declarations. Checking that a messagesent to a given object can be handled by that object (or by objects itdelegates to) is performed at run-time.

SELF also has no classes. Since SELF uses prototypes rather than classes,each object conceptually defines its own format, behavior, and inheritance(rather than having a separate class object to define this). A naive implementationof this approach would require that each object explicitly implement bothits own class-like format, method, and inheritance information, and itsown instance-like state information. However, SELF uses an implementationtechnique that allows it to regain much of the storage efficiency of sharedclass information. This is possible because few SELF objects have totallyunique format and behavior. Instead, almost all objects are created bycloning some other object and then modifying the values of the assignableslots. Major changes in the format or inheritance of an object can onlybe accomplished by invoking special primitives. A prototype and the objectscloned from it, identical except for the values of their assignable slots,are called a clone family. In the SELF implementation, objects arerepresented by the values of their assignable slots, if any, and a pointer(not visible to the user) to a structure called the object's map;this map is shared by all members of the same clone family. Maps are immutableso that they may be shared by objects in the same clone family. However,when the user changes the format of an object or the value of one of anobject's constant slots, the map no longer applies to the object. In thiscase, a new map is created for the changed object, starting a new clonefamily. The old map still applies to any other members of the originalclone family.

From the implementation point of view, maps look much like classes,and achieve the same sorts of space savings for shared data. However, mapsare not visible at the SELF language level, but are instead consideredpart of the language implementation [CUL89]. This allows the user to seea model in which each object defines its own format, methods, etc., whileat the same time permits the elimination of redundancy where this is possible.Users may also create user-visible objects which serve as shared behaviorrepositories (and to which other objects can delegate to obtain sharedbehavior). These objects are called traits objects. The creationof traits objects is independent from the existence of maps; the user neednot create traits objects, while the implementation automatically generatesmaps.

System Object Model (SOM)

The SOM description for "types and classes" is essentiallythe same as that described in the OODBTG Reference Model entry in thissection in that a "type" defines a protocol shared by a groupof objects, called "instances" of the type and a class definesan implementation shard by a group of objects.

In SOM, all objects are derived from a SOM root object which definesthe essential behavior common to all SOM objects. In addition, SOM hasa root class for all SOM metaclasses which defines the essential behaviorcommon to all SOM classes. The SOM metaclasses define factory methods thatmanufacture objects of any class for which they are the metaclass.

OLE Component Object Model

Unlike C++, where objects are defined using class definitions whichgenerate user-defined types, Windows Objects are defined in terms of theinterfaces they support. Since all objects support at least one interface(IUnknown), all Windows Objects are at least of type IUnknown,and can be treated as being of another type by using a different interface.Because of this mechanism, there is no single user-defined type associatedwith a Windows Object class, as there is with a C++ class (examples ofstandard Windows Objects include such things as windows, dialogs, messages,controls, and GDI objects, such as pens, brushes, fonts, and bitmaps).

A Windows Object class is identified as such only through a class ID(a structure called CLSID) that associates an object with a particularDLL or EXE in the file system (e.g., the application that implements theobject). The class ID is stored in a registration database, along withinformation that defines where the object "lives" and characteristicsthat a potential user may wish to know without having to actually instantiatethe object. The registration database is stored in REG.DAT in the Windowsdirectory. Under Windows Objects, a class object represents a specificclass ID, is obtained by a specific OLE API, and supports an interfacecalled IClassFactory. Every component object class (but not all types ofWindows Objects) must have a unique CLSID associated with it in the registrationdatabase (i.e., Windows Objects can exist that do not have defined classesin this sense).