[Off] The ... of Multiple Inheritance (was: Re: [plt-scheme] Lightweight object system)

>
> To put it another way - will an object system ever be part of RnRS,  
> or is
> this verging on heresy ;)
>

Judging from the heated discussions on the R6RS mailing list about  
much more innocent extensions, I'd say it's definitely heresy. ;-) In  
my impression, the design of OO systems is as controversial as Bible  
interpretation, and perhaps that's also the reason why there isn't an  
SRFI for an OO extension yet. Personally, I'll use ROOS for now.

By the way, related to that a question has bothering me for quite  
some time. Sorry, it's not directly PLT scheme related. I've always  
wondered why so many people are opposed to multiple inheritance. To  
me, it looks quite useful. Perhaps I did something wrong, but in my  
limited Java experience I frequently ended up spending a lot of time  
writing wrappers for the APIs of class B in a class A storing an  
instance of class B (on the basis of some sort of A+B interface),  
because there was no multiple inheritance.

Wikipedia mentions the 'diamond problem' of multiple inheritance, but  
I fail to see its deeper perils. Say, class B and C are subclasses of  
A, and D is a subclass of B and C, who both implement method foo.  
Okay, so we can suppose that D uses the foo of, say, B, because B has  
been declared before C as a superclass. I think that's a common way  
to deal with this . So for an instance d of D, (is-a d B) and (is-a d  
C) are true, but d cannot access C's foo method. If that is a  
problem, why not just have an operator (as-if d C), which magically  
transforms d into an instance of a class that behaves as if C was  
declared before B as a superclass in D. Then (as-if d C) calls method  
foo of C instead of B. It should then be possible to test both  
strictly, e.g. (instance-of (as-if d C) D) ==> false, and less  
strict, e.g. (is-a (as-if d C) D)==> true. Of course, that's just one  
of many possible solutions.

Are there some more serious arguments against multiple inheritance?  
What's so bad about it? It seems to me that storing a banana inside  
an apple and writing a lot of banana methods for apples is not  
necessarily more clear and less error-prone than just creating a  
somewhat artificial apple-banana, or is it?

Just being curious.

Best regards,

Erich