A Prototypal Perspective

The TADS 3 object model is not class-based. By this we mean that in a traditional class-based model classes are used to provide the blueprints from which instances are derived that do the actual work of the program. Classes do not generally receive messages except to create new objects. The purpose of the class is to provide the blueprint for a new object.

Inheritance

TADS adopts a distributed inheritance scheme. This means that an objects definition consists only of those properties that it directly defines. The other properties that constitute the state and behavior of the object, and which are inherited from other objects, are not part of the object definition, but are determined through a traversal of the object’s inheritance hierarchy.

To explore this further, let’s examine the following representation of an object’s definition:

<objectName>: classList

{

<directlyDefinedPropertyList>

}

The <> symbols indicate that these elements are optional. Only the class list is required in an object definition.

Traversing the Inheritance Hierarchy

Inheritance in TADS 3 moves down the inheritance tree of a trait, and then across to the next trait in the class list, from left to right, iterating down through each inherited trait in this fashion until we have either found the property being evaluated or have reached the end of the hierarchy.

Complex as this process seems, it is an automatic one, and the