[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why Single Inheritance Restriction?

This page is part of the web mail archives of SRFI 76 from before July 7th, 2015. The new archives for SRFI 76 contain all messages, not just those from before July 7th, 2015.

   From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
   Date: Tue, 20 Sep 2005 12:21:39 +0200

   Multiple inheritance sure would enhance the functionality, but I guess
   we thought that the added usefuless was too small to justify the
   significant complications in semantics and implementation.

It's usefulness is small unless you want multiple inheritance,
in which case it is required.  Given all of the bells and whistles,
my assumption is that the authors want this to be the be all and
end all of record proposals.  Leaving out multiple inheritance
means that someone else is going to write a record SRFI that
provides it.

   I have trouble following your rationale---if you haven't found
   multiple inheritance useful, why is adding it better than leaving it
   out if single inheritance stays in?

Because 'no inheritance' and 'multiple inheritance' are the
two ends of the spectrum.  'Single inheritance only' is in
the middle.  You need two rationales, one why inheritance is
needed and the other why single inheritance is enough.

   Also, could you elaborate what
   you mean by "as far as the predicates are concerned"?

It's clear how multiple inheritance works with the predicates.
How it works with the initializers isn't so obvious.  For that
matter, I am not sure how the initializers work for single
inheritance.  Are the supertype initializers called?  In some
particular order?  What are the semantics of a partially
initialized record?  This is a problem for Java programs; it
would be nice to avoid it in Scheme.