Needed: Real-world examples for Python's Cooperative Multiple Inheritance

[Mark Wooding]

John Nagle <nagle at animats.com> writes:

> I'd argue that a better implementation would require that when there's
> a name clash, you have to specify the class containing the name. In
> other words, if A is a subclass of B, then B.foo() overrides
> A.foo().  But if C is a subclass of A and B, and there's an A.foo() and
> a B.foo(), calling self.foo() in C should be an error, because it's
> ambiguous. You should have to specify the parent class, using "super".

How peculiar.  `super' is /specifically/ for working out dynamically
which superclass to delegate behaviour to, because working it out
statically isn't possible in general.

> The same issue applies in the other direction.  If A and B are
> subclasses of D, and A.foo() and B.foo() are defined, and D calls
> self.foo(), that's an ambiguity and should be reported.

No it isn't.  It's downward delegation, which is an essential feature of
object oriented design.

> @This catches the case where two classed both inherit from, say
> "threading.thread", each expecting to have a private thread.

Why on earth would anyone do such a bizarre thing?  If you want a
private thread, then attach one as an attribute.  Inheriting is simply
madness.

> Someone then inherits from both classes, getting totally unexpected
> results when one of the "run" methods is chosen somewhat arbitrarily.

But only because the original design was crazy.  If you make a subclass
of `thread' it's because you wanted a more specific kind of thread.  If
you subclass two other subclasses of `thread', it's because you wanted a
very specific kind of thread which included the behaviour of those other
two subclasses.

> Detecting a clash requires machinery CPython's lookup machinery
> currently lacks. 

What you see as a `clash' is more likely deliberate factoring of
behaviour.

Again, you seem to think that C++ is, for some reason, the `one true
way'.  It really isn't.  Actually, it's a pretty poor way.  But that's
not the point: the point is that there are other ways, and if you
stopped whining about how Python's object system might theoretically go
wrong if you try to use it like it was C++ and started thinking about
how to actually make effective use of the features it offers -- features
which long predate Python, and have been thought about over many years,
in languages such as Zetalisp, Common Lisp, Dylan, Scheme, and variants
of Smalltalk -- you might got on much better.

-- [mdw]