Greetings.
Any comments made by me will certainly not be the
'pythonic' way to do things, but I would like to
make a few comments on the subject, and possibly
weave in a few questions of my own.
(I took a brief detour into Common Lisp after joining
this list, not too long ago. Thanks Mr. Gauld.)
>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.
I agree with that satement.
My understanding is to move from the highest level
of abstraction to the detailed, or idividually
specific.
>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.
Personally, I see nothing wrong with redefining a
method in a subclass. From my limited dealings with
multiple inheritance, it seems to me the less you have
to deal with it, the better off you are.
I think my general view would be to cut out any excess
complexity unless its absolutely necessary.
Ostiches did fly at one point in time, and I'm pretty
sure all birds did. (though I'd have to reseach that
to be sure)
What do you all think about dealing with 'all birds
fly, but not these' based on an attribute?
Mass, or weight might be one factor...
Ostiches are too large to fly. (at least with their
current wing size)
>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.
I disagree, but then I come from the ruby language
which has an interesting take on MI.
Attributes and methods without the full complexity
of MI.
(though I'm certainly not an expert in ruby)
>Jeff
>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.
What would be the harm in having the fly() ethod in
ostrich perform a different action?
"Im flapping my wings to no avail, but I'm running
quite fast"
>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()
Where I come from, it wold look in the super class
for the fly() method when it wasnt found in ostrich,
and then you would have an action that wasnt right.
Ostriches dont 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.
What about subclassing bird with FlightlessBird?
As I learn more about the python way, I will be able
to
contribute something more usefull and intelligent.
I hope it was ok to post my general thoughts about it
here...
--Greg
>HTH,
>Alan G.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
