Type Derivation

Timor's approach of separating types from their implementations has proved to be a valuable tool for overcoming a number of problems in conventional languages. In Timor, subtyping, polymorphism and method behaviour are issues relevant only to the definition of types. By separating these from issues related to implementations, Timor is able to define subtypes involving diamond inheritance, subtypes which have multiple and repeated supertypes and the redefinition of methods.

 

The keyword includes has been introduced into Timor as an alternative to extends. Whereas the latter indicates a genuine subtyping relationship, the former indicates that a type definition includes the methods of another type without implying a subtype relationship. Consequently if a DoubleEndedQueue definition indicates that it includes the type Queue the compiler does not permit a DoubleEndedQueue variable to be assigned to a variable of type Queue. Together these two techniques (extension and inclusion) are referred to as derivation.

 

Following the Java approach to method collisions, Timor distinguishes between collisions merely in the names of methods and collisions of method signatures. Collisions of complete method signatures are treated as cases of redefinition, while collisions simply in the names of methods (i.e. where the signatures otherwise differ) are treated as overloading. When overloading occurs, each inherited method is considered to be a separate method. Thus discussions of collisions in the sequel refer to cases where the method signatures are indistinguishable.

 

It is possible in Timor to separate the redefinition of behaviour of a method from the overriding of its code, simply because behavioural redefinition is a matter which affects type definitions while overriding is an implementation issue. Thus in derived type definitions there is a section headed by the keyword redefines, which list the methods in question and allows the new behaviour to be informally redefined in comments.

 

As indicated in the section "Natural Language Orientation" Timor also supports a concept known as "views". A view is a set of related interface methods which can usefully be included in many types (using extends or includes), without embodying the central concept usually associated with a type. Timor views correspond to a certain class of adjectives, often ending in "able" and describing some aspect of many kinds of objects, often of quite different types. Here is an example of a Timor view which might usefully be included in the definitions of many types of devices and products.

view Switchable {
instance:  
op void switchOn();
op void switchOff();
enq Boolean isSwitchedOn();
}

This might for example be used to extend a type Radio, as follows:

type Radio {
extends:
Switchable;
instance:
setStation(...);
...
}

With this definition a Radio instance could be assigned polymorphically to a Switchable variable, e.g.

Radio aRadio = Radio::Impl();
Switchable s;
s = aRadio;

Views can, but need not, have implementations. They are normally defined explicitly, but they can also be defined retrospectively from methods in existing type definitions and used as if the type had been defined by extension. For example an instance of a type which had been declared (without the use of a view) with instance methods such as switchOn and switchOff, could be assigned to a view variable Switchable, provided that the corresponding method definitions are identical.