[Haskell-cafe] [Newbie] Quest for inheritance

[Ralf Lammel]

> Cédric Paternotte wrote:
> ...
> 
>  > 5. With this :
> http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/tr01-60.pdf
>  >
> 
> Gracjan Polak wrote:
>
> I've been thinking about slight generalization of this lately. Here are
> my semi-backed thoughts as of now.

I should have mentioned 
http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens2/
(again *not* using OOHaskell)

The actual example encodes Chris Rathman's shape benchmark.
The underlying story is somewhat similar to Gracjan's email.

Compared to the code that Gracjan posted,

- this code pinpoints another issue of this poormens' approach:
  get_super is quite obviously not enough if you end up wanting
  mutable objects. You need a setter as well. (My feeling here
  is that the encapsulation could be better. It would need
  coding effort to avoid that all data is public.)

- this code also shows how the "fake inheritance through data
  composition" approach blends with virtual methods: one uses an extra
  class per abstract/virtual method. (Clearly, one can potentially try
  to bundle some methods in a class.) An issue here is that client code
  might get bloated with constraints: for datatype subtyping
  *and* all used virtual methods. Alternatively, one can place 
  the OO methods (their functional counterparts) in the data capsules
  themselves! Then you get into the trouble of self references.

A more general and preliminary observation:
the entire approach is potentially more about
object *composition* (and perhaps delegation) 
rather than inheritance. Many OO evangelists 
consider inheritance as a concept that was used
too much in early OO times, while object composition
is often more appropriate and flexible. So one *might*
say that this approach does not encode a Java-inheritance
solution but it does an inheritance-to-object-composition
migration on the fly. So what Gracjan calls "Inherits"
(and I call subtyping or substitution) is perhaps more a
"delegates".

Ralf