How to call this right? (polymorphism independent from inheritance)

[Alex Martelli]

"Roman Suzi" <rnd at onego.ru> wrote in message
news:mailman.988790645.26320.python-list at python.org...
> Hello!
>
> The example below shows that polymorphism could be independent from
> inheritance.

Polymorphism _is_ independent from inheritance, yes.

> (And some people think it is true OOP approach (and multiple
> inheritance is wrong one), but it is underestimated in other langauges:
> Java, C++). The method is very powerful, because it doesn't need stupid
> abstract classes for every combination of attributes, and models the real
> world of objects more purely.
>
> Python supports this approach right out of the box
> (or so it seems).
>
> My questions are:
>
> 1. How to call it scientifically?

I suspect the name you want may be "signature-based polymorphism".

> 2. Will the code below really legal in __future__

I don't see why it should become illegal.

> 3. Do you think I am right in the text above?

I believe you may be missing some subtleties, such as the fact
that signature-based polymorphism IS crucial to certain core
parts of C++ (generic programming, aka templates; the Standard
C++ Library hinges on that), and the fact that the confusion
between inheritance and polymorphism is eased in Java by the
distinction it draws between class, and extends (inheritance),
and interface, and implements (polymorphism).

"Stupid abstract classes for every _combination_ of attributes"
are also avoided by any multiple-inheritance (mixin) approach,
and other ways to implement what Martin calls the "interface
segregation approach" (multiple 'implements' in Java, for ex).

All in all, while the realization that inheritance need not be
more than just a handy code-reuse approach, and polymorphism
is quite a different (and more important) paradigm than that,
IS an important realization; it seems to me that your actual
presentation may do some level of injustice to Java and C++.

Whether signature-based polymorphism *DOES* "model the real
world more purely" -- it depends!  To reuse a classic example,
my client-code may typically not request of its object argument
just that "it implements a method Draw()" -- it may make more
sense to have it require of its argument to "satisfy protocol
Artist", or "satisfy protocol Gunslinger", or "satisfy protocol
Lottery" -- each of these protocols may have a single method
called "Draw()", but the identity of names, and signatures, is
hardly any sort of modeling guarantee about the semantics of
such methods.  Which is why some of us really like PEPs 245
and 246, about interfaces and protocols... to *allow* modeling
semantics (best expressed in such terms as interfaces and
protocols) to get down directly to language-level, rather than
*having* to rely on JUST signature-based polymorphism, or on
"stretching" the semantics of classes and inheritance to very
different ends than the code-reuse level they so nicely supply.


Alex

signatures, is hardly a