2.2.9 Objects

An object is either NIL or a reference to a data record paired with a method suite, which is a record of procedures that will accept the object as a first argument.

An object type determines the types of a prefix of the fields of the data record, as if ``OBJECT'' were ``REF RECORD''. But in the case of an object type, the data record can contain additional fields introduced by subtypes of the object type. Similarly, the object type determines a prefix of the method suite, but the suite can contain additional methods introduced by subtypes.

If o is an object, then o.f designates the data field named f in o's data record. If m is one of o's methods, an invocation of the form o.m(...) denotes an execution of o's m method. An object's methods can be invoked, but not read or written.

If T is an object type and m is the name of one of T's methods, then T.m denotes T's m method. This notation makes it convenient for a subtype method to invoke the corresponding method of one of its supertypes.

A field or method in a subtype masks any field or method with the same name in the supertype. To access such a masked field, use NARROW to view the subtype variable as a member of the supertype, as illustrated below.

Object assignment is reference assignment. Objects cannot be dereferenced, since the static type of an object variable does not determine the type of its data record. To copy the data record of one object into another, the fields must be assigned individually.

There are two predeclared object types:

ROOT	The traced object type with no fields or methods
UNTRACED ROOT	The untraced object type with no fields or methods

The declaration of an object type has the form:

    TYPE T = ST OBJECT
               Fields
             METHODS
               Methods
             OVERRIDES
               Overrides
             END

where ST is an optional supertype, Fields is a list of field declarations, exactly as in a record type, Methods is a list of method declarations and Overrides is a list of method overrides. The fields of T consist of the fields of ST followed by the fields declared in Fields. The methods of T consist of the methods of ST modified by Overrides and followed by the methods declared in Methods. T has the same reference class as ST.

The names introduced in Fields and Methods must be distinct from one another and from the names overridden in Overrides. If ST is omitted, it defaults to ROOT. If ST is untraced, then the fields must not include traced types. (This restriction is lifted in unsafe modules.) If ST is declared as an opaque type, the declaration of T is legal only in scopes where ST's concrete type is known to be an object type.

The keyword OBJECT can optionally be preceded by ``BRANDED'' or by ``BRANDED b'', where b is a text constant. The meaning is the same as in non-object reference types.

A method declaration has the form:

    m sig := proc

where m is an identifier, sig is a procedure signature, and proc is a top-level procedure constant. It specifies that T's m method has signature sig and value proc. If ``:= proc'' is omitted, ``:= NIL'' is assumed. If proc is non-nil, its first parameter must have mode VALUE and type some supertype of T, and dropping its first parameter must result in a signature that is covered by sig.

A method override has the form:

    m := proc

where m is the name of a method of the supertype ST and proc is a top-level procedure constant. It specifies that the m method for T is proc, rather than ST.m. If proc is non-nil, its first parameter must have mode VALUE and type some supertype of T, and dropping its first parameter must result in a signature that is covered by the signature of ST's m method.

Examples. Consider the following declarations:

    TYPE
      A  = OBJECT a: INTEGER; METHODS p() END;
      AB = A OBJECT b: INTEGER END;

    PROCEDURE Pa(self: A) = ... ;
    PROCEDURE Pab(self: AB) = ... ;

The procedures Pa and Pab are candidate values for the p methods of objects of types A and AB. For example:

    TYPE T1 = AB OBJECT OVERRIDES p := Pab END

declares a type with an AB data record and a p method that expects an AB. T1 is a valid subtype of AB. Similarly,

    TYPE T2 = A OBJECT OVERRIDES p := Pa END

declares a type with an A data record and a method that expects an A. T2 is a valid subtype of A. A more interesting example is:

    TYPE T3 = AB OBJECT OVERRIDES p := Pa END

which declares a type with an AB data record and a p method that expects an A. Since every AB is an A, the method is not too choosy for the objects in which it will be placed. T3 is a valid subtype of AB. In contrast,

    TYPE T4 = A OBJECT OVERRIDES p := Pab END

attempts to declare a type with an A data record and a method that expects an AB; since not every A is an AB, the method is too choosy for the objects in which it would be placed. The declaration of T4 is a static error.

The following example illustrates the difference between declaring a new method and overriding an existing method. After the declarations

    TYPE
      A = OBJECT METHODS m() := P END;
      B = A OBJECT OVERRIDES m := Q END;
      C = A OBJECT METHODS m() := Q END;

    VAR
      a := NEW(A); b := NEW(B); c := NEW(C);

we have that

    a.m()  activates  P(a)
    b.m()  activates  Q(b)
    c.m()  activates  Q(c)

So far there is no difference between overriding and extending. But c's method suite has two methods, while b's has only one, as can be revealed if b and c are viewed as members of type A:

NARROW(b, A).m() activates Q(b)

NARROW(c, A).m() activates P(c)

Here NARROW is used to view a variable of a subtype as a value of its supertype. It is more often used for the opposite purpose, when it requires a runtime check.

The last example uses object subtyping to define reusable queues. First the interface:

    TYPE
      Queue = RECORD head, tail: QueueElem END;
      QueueElem = OBJECT link: QueueElem END;

    PROCEDURE Insert (VAR q: Queue; x: QueueElem);
    PROCEDURE Delete (VAR q: Queue): QueueElem;
    PROCEDURE Clear  (VAR q: Queue);

Then an example client:

    TYPE
      IntQueueElem = QueueElem OBJECT val: INTEGER END;
    VAR
      q: Queue;
      x: IntQueueElem;
      ...
      Clear(q);
      x := NEW(IntQueueElem, val := 6);
      Insert(q, x);
      ...
      x := Delete(q)

Passing x to Insert is safe, since every IntQueueElem is a QueueElem. Assigning the result of Delete to x cannot be guaranteed valid at compile-time, since other subtypes of QueueElem can be inserted into q, but the assignment will produce a checked runtime error if the source value is not a member of the target type. Thus IntQueueElem bears the same relation to QueueElem as [0..9] bears to INTEGER.