Natural Language Orientation

Object orientation has provided, and continues to provide, a useful paradigm for programming language design. However, it has some limitations. If one thinks of objects as corresponding to nouns in natural language, to what then do the other parts of speech correspond, e.g. verbs, adjectives, adverbs?

Verbs mainly imply action, and are in most cases used to describe actions performed on nouns. In this sense it is reasonable to see the actions which can be performed on objects (i.e. methods) as the verbs of object-oriented languages.

What about adjectives then? These qualify nouns in a descriptive manner, e.g. a fast car, an old man. Such simple adjectives are partly reflected in OO languages by means of attributes associated with a type, e.g. an attribute "maximum speed" in a car object (with an appropriate value) can reflect "a fast car", and a "date of birth" attribute in a person object can similarly indicate an "old man". But these techniques reflect the precision of computers, rather than the fuzziness of natural language (e.g. what speed must a car be able to attain before we can call it fast or how old must a person be before he is old?) Fortunately these issues are not so pressing, and we do not pursue them here.

However OO languages cannot normally model adjectives well. Some adjectives can be expressed as groups of related methods. Such adjectives often end in English with the suffix "–able", for example "openable" (which might be represented by methods such as "open", "close" and "isOpen". Timor provides a mechanism called "views" to support this concept.

Over time the adjectives which we apply to particular nouns can change. Provided that these are represented as attributes in the sense described above, that is not so serious, because we can change the values of attributes in OO languages.

A bigger problem is caused by the fact that nouns can be used to describe specialisations of other nouns. For example we can describe a person simply as a person, with attributes such as name, address, date of birth, etc. and we can change all of these attributes. But if a person is studying we can describe him using a different noun, i.e. as a student (i.e. a studying person). OO languages have built on this linguistic feature by introducing the concept of derived types (i.e. subtyping). This in effect allows a further set of attributes to be associated with a person (e.g. his university, his course, etc.) In principle that is a very effective programming language technique, for example allowing objects to be used polymorphically.

So where is the problem? How OO languages typically integrate subtyping leaves no room for changes. Of course a programmer can modify the information about a course which a student is taking, etc. But in OO languages one cannot change the fact that he is a student. However, in reality people do not remain students for ever, they probably later start an employment, thus becoming employed people, or simply employees. OO subtyping techniques will also allow us to define a person as an employee, but will normally not allow us to change a student into an employee. For some programming applications (e.g. a university student management system or a payroll system) this is not a special problem, but in other cases it can be, if the application is concerned with handling more than one aspect of a person, for example where a student graduates and later becomes an employee of the university. There are of course ways of getting round such problems, but they do not flexibly cope with changes.

The problems can get even more difficult to handle in many OO languages if for example the person is both a student and an employee at the same time, i.e. a studying, employed person. (This situation is called diamond inheritance and is not supported in a flexible way in languages such as Java.) And then there is also the equally difficult issue of repeated inheritance, where for example a person has more than one employment and/or is studying at more than one university. In such cases OO languages are not usually in the position to provide flexible components which can simply be re-used or can be used alongside each other to model such a person.

The fundamental problem is that OO languages do not generally provide the additional attribute sets (representing student features, or employee features) separately from the person features. What the Timor designers consider to be missing are separate components independently representing these additional features, i.e. representing adjectives such as studying or employed without having a person part automatically attached.

It is interesting to note that such adjectives are usually derived from verbs (e.g. to study, to employ) and are parts of speech known as participles. Unfortunately, however, not all participles can be modelled simply as sets of attributes. A participle such as synchronised or monitored requires more active components. In this case too Timor provides a new kind of component, which is described in the book "TIMOR-An Object- and Component Oriented Language" [7], which can be downloaded on this website.