OOP (was Re: Extensible records (was Re: Existential types, object-orientation.))

Jaroslav Tulach tulach@kolej.mff.cuni.cz
Sun, 9 Nov 1997 22:19:56 +0100 (CET)


Hello,
I tried to study problem of inheritance in typing theory in my master
thesis. I still not finished it but here I some comments I noticed.
 
#I think that to allow true OOP in cleant we should add one more feature
#:
#Extensible records. I mean something like
#
# :: Point = {x :: Real;y :: Real}
#
# :: Circle = { Point & r :: Real}

Extensible records could solve some problems but the examples are too
restrictive. Here are some more complex:

  :: Point a b = { x :: a, y :: b } 
  // point on 2D with coordinates of different types

  :: Circle a = { Point a a & r :: a }
  // circle that extends point but with the same type of coordinates

This examples should illustrate the problems that arrives when one does
not restrict himself to type without type variables. Because of following
questions:

  Is Circle Int subclass of Point Int Real?
  Is Circle Int subclass of Point Int Int?
  When a is subclass of b is Circle a subclass of Point b?

Please notice that these are simple questions but they can be complicated
as I show in following cases:

  :: OneWay a b = { oneWay :: a -> b }
  :: RoundTrip a b = { OneWay a b & backWay :: b -> a }

This example is about variance and covariance of arguments (I will write a
<= b if b is subclass of a). Here is the major rule for covariance:

  a => c & b <= d  then  a -> b <= c -> d

This rule can be obtained when one thinks about how subclassing of
parameters influence subclassing of whole funcitions.

From it we have:

  a => c & b <= d then (OneWay a b) <= (OneWay c d)

But we should realize that for RoundTrip the conditions are more
restrictive.

  If RoundTrip a b <= RoundTrip c d then the only possible solution for
  this problem is that a == c and b == d.


#  move :: (Real,Real) a -> a | a is Point

The a is Point is good construct but because of covarince we need also
another. I have found out that sometimes it is needed to restrict the
variable from up and also from down.

Example:

   move :: .... | a is Point & Circle is a

#What we have now are objects just like they have in Pascal.
#We lack only the multiple inheritance to get the C++ objects.

As for multiple inheritance I think one can succesfully use "interfaces"
as in Java. By interface I mean the original classes hierarchy from Clean 
1.0




The all text above contains only ideas, that I would like to discuss
about. It is not as precise as I would like it to be. But I tried to
describe the problem that could arrive when records with variables would
be allowed to have subclasses (and I think that without it we lose whole
beauty of current clean typing system). 

Jarda

PS: I working on this problem for one year and I still looking for a
literature. Does anyone ever seen something like this?

/**
* @author   Jaroslav Tulach
* @see      http://www.kolej.mff.cuni.cz/~tulach
*/