Variable inheritance

[Delaney, Timothy]

> > class Line(Point):
> >   ...
> >
> > just because line could be made of two points.
> 
>    Of course. Now THIS is bad design. Line IS NOT a point, hence, no
> inheritance should occur. Line CONSISTS of two point, so
> 
> class Line:
>    def __init__(self, p1, p2):
>       self.p1 = p1
>       self.p2 = p2
> 
>    But grey mouse DOES NOT "contains" grey color. The mouse 
> IS really grey
> thing, hence I used inheritance.
> 
>    This is difference between "thing IS a thing of the class" 
> and "thing
> CONTAINS things".

I would dispute this. A "grey mouse" is actually a mouse which has grey fur.

Let's take the corresponding two things: myself, and my hair. I am a human
male, and I have dark brown hair. Therefore, using the same logic, you would
say that I should inherit from "Human" and "DarkBrownColour"

	class Me (Human, DarkBrownColour):

However ... my skin colour is pinkish. My beard contains lots of red,
strawberry blonde and (depending on how stressed I am) grey. As I get older
I expect my hair colour to change.

In this situation, what should happen? Do I need to change my base class
because my hair is changing colour? Doesn't seem right.

Hair colour is instead an *attribute* of me. I am the object, I *have*
dark-brown hair (mainly ;). I am 172cm tall - another *attribute*. I am
currently holding a can of coke - perhaps that could be represented by
aggregation.

Object-systems rarely model the real world well, and I find most attempts to
do so end up being very contrived. In particular, most object/class
heirarchies which attempt to model the real world end up being *very*
contrived.

The only real use I've found for multiple inheritence, beyond trivial
examples, is for mix-in classes (as has already been suggested in this
thread). A good example is one I wrote about 5 years ago. At that time, the
Metrowerks PowerPlant framework had three methods as part of the interface
for a "Frame" - "MouseEnter", "MouseLeave", "MouseWithin". Unfortunately,
through oversight or for another reason, these methods were never called!

I wrote a mix-in class (LMouser, following the naming conventions of the
framework). Inherit from this class, and Frame, and suddenly these methods
were called at the appropriate times. I didn't have to modify the Frame
class, or any other class. It added functionality to Frames. It required
that the class it was mixed into inherited from Frame, or a subclass of
Frame i.e. it *couldn't* be used without MI.

This is where multiple inheritence is useful.

Tim Delaney