[Tutor] design questions: pythonic approach to ostriches

[Smith, Jeff]

This is an excellent observation and points to the real problem with the
original question.  The problem is that the base class has more features
than some of the classes that will be dervied from it which is usually
just plain wrong.

Think about it in the abstract.  The Bird class makes the statement: all
birds fly.  Then you want to turn around and define a Bird that doesn't.
Even doing

def fly:
	pass

makes no sense since what you've really done is to re-defined what 'fly'
means for this bird.  Again in the abstract:  all birds fly and for some
birds that will mean that they don't.

The only sensible solution to this that will cause the least confusion
from a maintenance stanpoint and allow for the largest possible reuse is
multiple inheritance for languages that support it.  

Jeff

-----Original Message-----
From: tutor-bounces at python.org [mailto:tutor-bounces at python.org] On
Behalf Of Alan Gauld
Sent: Sunday, April 24, 2005 3:48 AM
To: Brian van den Broek; Tutor
Subject: Re: [Tutor] design questions: pythonic approach to ostriches


> I do remain a bit surprised that there seems to be no way to
implement
> what I naively thought would be the obvious solution -- to remove an 
> inherited method from the instance's dictionary.

You can, as Kent said, override the method to do nothing. Some
languages, like Eifell offer better support for that than others.

But there is a danger in removing methods too. By doing so you break one
of the fundamental principles of inheritence: that everywhere that you
use the superclass you can use the sub class.

If you remove the fly() method from your subclass of birds code like
this will break:

birds = [ aSwallow, anOstrich, anEmu, anEagle]

for bird in birds:
   bird.fly()

Whereas if you simply make fly a null method you can still call it but
nothing happens - a lot safer...

But conceptually the problem (and it is common) is that bird has a
fly() method when not all birds can fly - the object model is broken at
a high level of abstraction.

HTH,

Alan G.


_______________________________________________
Tutor maillist  -  Tutor at python.org
http://mail.python.org/mailman/listinfo/tutor