[Tutor] class overriding question

[Alan Gauld]

You've got it right Brian. It is this ability to change the way
*existing* code works that makes OOP more than a neat way to
package data and functions. This is polymorphism at its
most powerful.

Its why in a C++/Java world the convention is to write
hook methods that are called by the public methods. Thus
sub classes can override the hook methods and change the
behaviour of the public methods, without changing the
basic sequence of processing. The common example here
is a shape heirarchy:

Shape defines a move method. move() calls delete()
and draw() hooks.

New classes override delete and draw and get move for
free because it will always call the hooks in the
right sequence and each subclass will actually do
the appropriate work.

Its another reason why you should never refer to
an object or method *calling* another method
(as Pilgrim does). Rather think of the method
sending a *message* to the self object which
invokes the appropriate method. This decoupling
of message from method is a vitally important
concept in OO and onvce you understand the concept
of messages being sent resulting in methods
being invoked OOD becomes much easier to grasp.
This is explicit in Lisp, Smalltalk and Objective C
where methods may have completely different names
to messages, and multiple messages may invoke the
same method - possibly with different default
parameters - a very powerful technique! it's just
about possible to do this in Python with lambdas
etc but its messy.

Alan G.

----- Original Message ----- 
From: "Brian van den Broek" <bvande at po-box.mcgill.ca>
To: "Tutor" <tutor at python.org>
Sent: Saturday, December 18, 2004 1:31 PM
Subject: [Tutor] class overriding question


> Hi all,
>
> instead of sleeping, I've been up all night finally attacking my
> apprehension about classes. I think I'm mostly getting the hang of
it --
> I managed to convert a 300 line procedural script into (what I think
is)
> a fully object-oriented approach. :-)
>
> I made a lot of use of Mark Pilgrim's Dive Into Python
> <http://diveintopython.org/>, but Pilgrim said something that I'd
like
> to check my understanding of. In section 5.5
> <http://diveintopython.org/object_oriented_framework/userdict.html>
he
> writes:
>
> > Guido, the original author of Python, explains method overriding
this
> > way: "Derived classes may override methods of their base classes.
> > Because methods have no special privileges when calling other
methods
> > of the same object, a method of a base class that calls another
> > method defined in the same base class, may in fact end up calling
a
> > method of a derived class that overrides it. (For C++ programmers:
> > all methods in Python are effectively virtual.)" If that doesn't
make
> > sense to you (it confuses the hell out of me), feel free to ignore
> > it. I just thought I'd pass it along.
>
> I think I get this, but my inexperience with classes and Pilgrim's
> rhetorical flourish make me doubt myself. I think the following
three
> ways of saying it all say the same thing (to a greater or lesser
degree
> of precision) as the quote from Guido above. Do I have the idea?
>
> Say class spam defines a method ham, and a method eggs, where ham
calls
> eggs.  Further say class foo is derived from spam and overrides its
eggs
> method, but not its ham method. Then calling the ham method of an
> instance bar of foo (and thus calling the ham method of spam, as foo
is
> a spam), will call the eggs method of foo, despite the fact that ham
is
> a method of spam, and within spam points originally to spam's
version of
> the eggs method.
>
> Alternatively, when calling bar.ham(), Python essentially says "OK,
> bar's a foo. Does foo have a ham method? No, but it is derived from
> spam. Does spam have a ham method? Yes, and it calls an eggs method.
> Since bar's a foo, I should first look to see if foo has an eggs
method.
> (Nevermind that it was code in spam that started me off looking for
> eggs.) Golly good, it does. So I will use that and not even bother
to
> look at spam's version of eggs."
>
> One other way: if we represent class inheritance as a tree, an a
given
> instance is of a class at level n in the tree, any search for a
method
> begins with the instance class and works up the tree to the ultimate
> base class at level 1, no matter how high up the tree the search for
the
> method was initiated. And, in that search up the tree, the first
> correctly named method to be found will be used. (I'm using the
> mathematician's notion of trees with roots at the top.)
>
> Anyway, I hope I've both made sense and have got the idea right.
>
> Best to all,
>
> Brian vdB
>
>