The "basic level" is a concept from cognitive psychology. In natural languages, basic level categories represent the most important concepts and are known by the most common and shortest words. The words "home," "dog," "tuna," and "pencil" define basic level categories.
Below the basic level, categories share the same "functional" properties as basic level categories, but become increasingly specific. So, "Dalmation" is a kind of "dog" and "three year old Chihuahua with a limp" is an even more specific kind of dog.
Above the basic level, categories share the same "conceptual" properties, but become increasingly abstract. The class "carnivore" is more general than "dog" and the class "animal" is even more general than "dog." Members of classes above the basic level may share no functional properties. The class "animals" unites the classes "tuna fish" and "aardvarks" into one concept, but tuna fish and aardvarks have nothing in common. One eats squid; the other eats termites. One breaths air; the other breaths water. One swims; the other waddles. Only by a leap of imagination do we say that tuna fish and aardvarks are both animals.
Many applications use classes above the basic level. In database, an index in a library describes many kinds of objects: books, magazines, photographs, videos, music recordings. . . . Each object has its own unique properties not shared by other objects. When a library patron asks for "all items by David Byrne or the Museum of Modern Art," the query processor must evaluate each object according to its own unique properties. In graphical user interfaces, objects have unique properties: buttons, text boxes, icons, and menus all have distinct properties. When a user "drags and drops" one object onto another, the specific action taken depends on both the type of the dragged object and the type of the object it is dropped onto.
Groups of heterogeneous objects occur throughout most application domains: databases, I/O systems, compilers, graphics, and so on. As applications become more complicated, developers encounter classes above the basic level more often.
Developers have many techniques for managing type distinctions above the basic level: variant records, typeid, typecase, and multimethods. Developers also have various patterns to implement workarounds for multimethods when using conventional object-oriented languages: mediator pattern, visitor pattern, and double dispatch. But, multimethods are the safest and most expressive techique of all.
Above the basic level, classes are defined in a bottom-up way and they conform to covariant type relationships. Method dispatch requires runtime type checking. Classes describe unions of properties.
Below the basic level, classes are defined top-down and they conform to contraviarint type relationships. Method dispatch requires compile-time type checking. Classes describe intersections of properties.
By definition, "post-object" programming languages provide both strong compile-time type checking below the basic level and strong runtime type checking above the basic level.
Most contempory object-oriented programming languages emphasize programming on one side of the basic level or the other. Strongly typed object-oriented languages (like C++, Eiffel, and Java) support class hierarchies below the basic level, but provide mediocre runtime type support for classes above the basic level. Weakly typed langages with multimethods (like CLOS) support classes above the basic level, but provide very little optimization or compile-time type checking for classes below the basic level. To work around the limitions of individual languages, many applications combine Smalltalk or Visual Basic for programming above the basic level with C++ for programming below the basic level.
The only languages that we know of, that qualify as post-object, are Cecil, Kea, and Polyglot, but only Cecil has a working optimizing compiler. We believe that Cecil is the first real post-object programming language.
Does post-object programming do something that object-oriented programming cannot do? We say, "Yes." Multimethods express class relationships above the basic level and compilers that implement multimethods can build the switch on type safely and automatically.
Each shift in technology improves the semantics that code can express, type check, and optimize. The Visitor pattern, the Mediator pattern, and double dispatch will become obsolete when languages provide multimethods to implement heterogeneous classes above the basic level.
Go to L. B. S. Raccoon's home page.
© Copyright 1996 by L. B. S. Raccoon. All Rights Reserved.