An alternative approach to bound methods

[Alex Martelli]

"Marcin 'Qrczak' Kowalczyk" <qrczak at knm.org.pl> wrote in message
news:slrn99a93s.vn8.qrczak at qrnik.zagroda...
> Thu, 22 Feb 2001 11:14:05 +0100, Alex Martelli <aleaxit at yahoo.com> pisze:
>
> > I *STRONGLY* disagree, because in the third case, AND IN IT ONLY,
> > inheritance and overriding come into play!!!
>
> Sure. So depending on whether you want recursive call to refer to
> the function itself or to its version overridden by inheritance,
> you would write either
>     foo
>     X.foo

> > _Normally_ the potential for polymorphism and overriding IS desired,
>
> In recursive calls to class methods? Not at all. If the overridden
> version calls me, it probably expects that I would do what I was
> supposed to do in the superclass. No matter if I do this by calling
> myself recursively or not.

Where do you read/infer the limitation to *class* methods?

> Remember that I am talking about class methods, which don't exist
> now at all. They can be currently expressed as module functions which
> are not subject to inheritance. Instance methods are normally called
> through self as always!

But how does a given function, whose def is inside a class, know
whether it's supposed to recurse through its (potential) overrider
(via a same-name method of the first argument) or by defeating the
override (via its bare name, or, equivalently if your proposal was
adopted, using itself as an attribute in its enclosing class)?

Recursion apart, what distinguishes, e.g., a method foo in class
Derived(Base), calling the version it overrides as Base.foo(self,x,y),
and a "class-method" bar calling the same-name class-method of
the base class as Base.bar(x,y,z)?  They're indistinguishable cases
now -- would they get distinguished in your proposal, and, if so, how?


Alex