|Q: OO type systems Daniel.Vogelheim@post.rwth-aachen.de (1998-09-13)|
|Re: Q: OO type systems email@example.com (Erik Schnetter) (1998-09-18)|
|From:||Erik Schnetter <firstname.lastname@example.org>|
|Date:||18 Sep 1998 23:01:24 -0400|
|Organization:||Institute for Astronomy and Astrophysics Tuebingen|
In comp.compilers Daniel Vogelheim <Daniel.Vogelheim@post.rwth-aachen.de> 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.
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 <email@example.com>
Return to the
Search the comp.compilers archives again.