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

Multiple inheritance, super() and changing signature

On Sat, 4 Jun 2016 09:52 pm, Gregory Ewing wrote:

> Ian Kelly wrote:
>> It can't belong to a subclass; the MRI guarantees that. But it's not
>> necessarily a superclass either.
> Er, yes, what I really meant to say was that it could
> be a class that got introduced into the MRO as a result
> of someone else subclassing your class.
> So when you make a super call, you really have *no idea*
> what it's going to call.

That's the nature of inheritance in a MI world. If you try to specify a
particular superclass manually, you're in the position of the archetypal
drunk looking for his lost car keys under a street light "because the light
is better here". Sure, you always know which class you're calling, but
sometimes its the wrong class!

That's the mind-twisting part of MI. Just because your class inherits from
K, doesn't mean that you should be calling K's methods. Until you (generic
you) come to terms with that, you're going to struggle with MI regardless
of what you do.

It might help to read Michele Simionato's articles about super, multiple
inheritance and related topics. Michele has been working with issues
related to MI for many years and has a lot to say about them.

Things to know about super:
Part 1
Part 2
Part 3

The wonders of super:

Mixins considered harmful:
Part 1
Part 2
Part 3
Part 4

Traits as an alternative to MI and mixins:

Generic functions as an alternative to mixins:

The Method Resolution Order:

Michele wrote:

"... the problem is multiple inheritance itself. Inheritance makes your code
heavily coupled and difficult to follow (spaghetti inheritance). I have not
found a real life problem yet that I could not solve with single
inheritance + composition/delegation in a better and more maintainable way
than using multiple inheritance."

and I think that is the most valuable lesson here. MI itself is, if not an
anti-pattern, at least a dangerous one.