Re: Q: OO type systems

Erik Schnetter <>
18 Sep 1998 23:01:24 -0400

          From comp.compilers

Related articles
Q: OO type systems (1998-09-13)
Re: Q: OO type systems (Erik Schnetter) (1998-09-18)
| List of all articles for this month |

From: Erik Schnetter <>
Newsgroups: comp.object,comp.compilers
Date: 18 Sep 1998 23:01:24 -0400
Organization: Institute for Astronomy and Astrophysics Tuebingen
References: 98-09-051
Keywords: OOP

In comp.compilers Daniel Vogelheim <> wrote:
> In most single-inheritance oject oriented languages, interface
> inheritance and implementation (code) inheritance are identified in a
> single construct. Many multiple-inheritance languages (like C++ and
> Eiffel) have adapted this scheme to multiple inheritance, while others
> chose allow arbitrary (non-cyclic) interface inheritance, but restrict
> multiple code inheritance.

> For example, the Sather language allows only classes at the bottom of
> the hierarchy (ie, classes with no siblings) to have code, which must
> be "inherited" via a separate statement. Java allows arbitrary
> interface inheritance, but only single interface+implementation
> inheritance, effectively embedding an implementation inheritance tree
> in the interface inheritance DAG. Many research languages seem to
> follow similar trends.

> I wonder, why is this done? Especially, what are the implications for
> compiler implementations of the respective languages?

The Sather type system separates between implementation and type
inheritance. Furthermore there is a difference between abstract
classes (interfaces) and concrete classes (classes containing code).
Type inheritance creates a hierarchical structure between different
abstract classes, while implementation inheritance allows one to reuse
code from other (possibly unrelated) classes.

A variable that is declared with such a concrete type, e. g.
x: INT
is not polymorphic. The type of the object x is exactly INT and cannot
be a subtype thereof, because the concrete class INT cannot have

Furthermore abstract and concrete classes are distinguished by syntax:
the names of abstract classes begin with the '$' character. Abstract
classes may need dispatching and thus are more expensive than concrete
classes. Sather has been designed to allow an efficient
implementation. Using variables with concrete types allows for a lot
of compiler optimizations without the need for a complicated
inter-procedural code analysis.

It is true that saying 'x:INT' is less general than 'x:$INT'; the
latter variable could also hold an object of type 'INTI', an infinite
precision integer value. This aspect of Sather's type system that
leads to rather specialized programs is somewhat alleviated by
parameterized classes which introduce another kind of genericity.

Erik Schnetter <>

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.