[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.

Richard Kelsey <kelsey@xxxxxxx> writes:

> Some discussion of the rationale would be helpful no matter 
> which choice is made.

Good point---we'll try to address that with the next draft.  The
general rationale is, I think, that the compound data types appearing
in many applications (say, abstract syntax trees, file mode bits, and
so on) have subtype relationships that single inheritance models
naturally.  I personally find it quite useful, even though it needs to
be used with care.  More specifically, it also works to implement
single-inheritance class systems, if you believe in and want one of

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

> Personally, I haven't found single or multiple inheritance
> to be particularly useful, but that doesn't make the current
> proposal any more palatable.  If inheritance is necessary, at
> a minimum I think that the procedural form should allow multiple
> inheritance as far as the predicates are concerned.

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?   Also, could you elaborate what
you mean by "as far as the predicates are concerned"?

Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla