[Python-3000] Special methods and interface-based type system

[Bill Janssen]

> > I'll still drop off a copy (of Common Lisp the Language, version 2),
> > but there's no need to wait.  It's on the Web at
> > http://www.supelec.fr/docs/cltl/clm/node260.html.  See in particular
> > the "change-class" operation at
> > http://www.supelec.fr/docs/cltl/clm/node305.html.
> >
> > I think I'm still confused (happens a lot :-) about our method
> > namespace discussion.  It seems to me that Python's method namespaces
> > work pretty much the same way that CLOS's do, already.  That is, you
> > don't "clobber" an existing method in a base class when you define a
> > new method by the same name in a derived class; you just mask it.  The
> > base class' method is still there, and can still be called explicitly.
> 
> OK, maybe I  misunderstood what you wrote. I thought I heard you say
> that "len" isn't just "len" -- it's the "len" defined by some
> interface (and presumably implemented in a base class), and if one
> defined a new "len" it wouldn't override the "len" defined by that
> interface (unless one explicitly stated that it did), it would just
> add a different method named "len". That would fly in the face of
> Python's lookup algorithm for methods (where the first "len" you find
> is the one you get). If that's not what you meant, all is probably
> well.

Actually, Python does both:  it overrides the base class' "len", and
adds a new "len" of its own.

class Base:

   def len(self):
      ...

class Derived(Base):

   def len(self):
      ...

Given an instance of Derived, I can make a call on Derived.len,
Base.len, or just let the default method lookup work, in which case I
get Derived.len().  So even if Derived.len() is overridden, Base.len()
is available.  The question then becomes more subtle: is the data
model maintained by the derived class consistent with that of the base
class?  But this is essentially off-topic:  I still think the concern
about "accidentally" overriding methods inherited from some base class
is misplaced, but still minor compared to the other issue of not being
able to figure out whether a value has a particular type.

By the way, it's interesting to look at the distinction made in Guy
Steele's (and Sun's) new research language, Fortress, between "traits"
(base classes), and "objects" (final classes).  Values are instances
of "object" types, but "object" types may inherit code and interfaces
from traits.  Only "object" types can define instance variables, which
means that much of the code in non-abstract "trait" methods is
eventually based on abstract method calls (and property getter/setters).

Bill