[Haskell-cafe] How to fulfill the "code-reuse" destiny of OOP?

Rogan Creswick creswick at gmail.com
Fri Oct 30 01:32:43 EDT 2009

On Thu, Oct 29, 2009 at 6:54 PM, Magicloud Magiclouds
<magicloud.magiclouds at gmail.com> wrote:
>  My concern here is about the data member inheriting. In OOP, when I
> inherit a class, I also got the members of it. But in haskell, how to
> inherit a "data"?

In my experience (almost entirely with Java), it is usually a bad idea
to inherit from a class in order to reuse data storage that the parent
class provides.  Encapsulation (or a decorator, if you prefer) is
often a safer choice.  If you really do need to meet the interface
provided by the parent class, while adding functionality (*and* you
can't just implement that interface independently of extending the
parent class), then it's often possible to still use a decorator, and
provide limited visibility accessors to the encapsulated field you
need (say, to pass into some unmodifiable legacy API).  When you get
down to it, it's extremely hard to design a full-fledged class so that
extending it actually makes sense, and can be done in a useful and
safe manner.  Extending concrete classes also brings along some
non-trivial maintenance headaches as well, since you now need to be
aware of changes to (some of) the non-public APIs when libraries are
upgraded, etc...  it's a mess.  This is a large part of why the
majority of the concrete classes in the Google Collections library are
final -- the limited benefit of extensibility isn't worth the design
and maintenance.

The point of that whole rant is that extending data-bearing classes
isn't necessarily a good idea, so before trying to find a way to do it
with haskell, it may be better to just encapsulate another data type,
which is trivial:

data InnerThing = A | B | C

data OuterThing = Outer { innerThing :: InnerThing, otherField :: Int }


> --
> 竹密岂妨流水过
> 山高哪阻野云飞
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

More information about the Haskell-Cafe mailing list