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

PLT Scheme's class system supported multiple inheritance for several  
years. Indeed, each major version change (100, 200, 300) includes  
some major change to the class system and how it relates to the core.

Our observation was that MI isn't needed. And it is hard to reason  
about. So instead, we switched to mixins, not the Common Lisp kind,  
but one that works really well with single inheritance. See

  http://www.cs.utah.edu/~mflatt/publications/index.html
  Scheme with Classes, Mixins, and Traits
  Flatt, Findler, and Felleisen

After working with Java-like OO systems for some 12 years now, I  
actually believe that inheritance in general is probably overrated. I  
will agree that organizing programs around class structures (data  
plus operations) appears to make a lot of sense. It is something I do  
even if I use modules only. (See recent post here) But other than  
that, I am still wondering why OO caught on.

-- Matthias





On Sep 5, 2007, at 6:01 AM, Erich Rast wrote:

>>
>> 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
>
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme