Unification of Methods and Functions

[David MacQuigg]

On 22 May 2004 11:50:18 -0700, moughanj at tcd.ie (James Moughan) wrote:

>David MacQuigg <dmq at gain.com> wrote in message news:<9hgpa0d2iq5bb2ko4sngs5i6v4og90vqej at 4ax.com>...
>> On 19 May 2004 23:26:38 -0700, moughanj at tcd.ie (James Moughan) wrote:
>> >David MacQuigg wrote:

>> I like your example, but not as a *substitute* for Animals_2.  It's
>> just too complex for non-CIS students at this point in the course.  I
>> think I understand your concerns about Animals_2.  I think the best
>> way to deal with those concerns is not by complicating the example, or
>> by taking out everything that could lead to problems, but rather by
>> pointing out the problems, and showing subsequent examples that fix
>> those problems, even at the expense of more complexity.
>> 
>> If you have a simple all-in-one alternative to Animals_2, show me.
>> 
>
>Again, clearly I have not communicated myself well - I mean a
>*completely* different example to the entire Animals approach.  The
>difficulty with writing a good Animals-type example comes from the
>things which it is trying to do, which aren't especially well
>expressed by a class-heirarchy.

What I am trying to do in Animals_2 is provide the simplest, most
learnable example of Python OOP, which has at least one of every basic
structure the students will encounter in a real program.  So I include
bound, unbound, and static methods, but not metaclasses or
descriptors.

Creating a good example like this is turning out to be more of a
challenge than I expected.  I'm fairly happy with Animals_2, but I
appreciate the "maintainability" problems you have pointed out, and
have added footnotes accordingly.  The examples in Learning Python are
too spread out in little pieces, and of course, no attention to the
issues you are concerned about.  If you know of another place I can
look for a good all-in-one teaching example, I am interested.

>Why not just take one of your earlier program examples, show the
>students what it looks like when object-oriented, then extend the
>class(es)?
>
>As I've mentioned, I don't like my example *at all* for your teaching
>purposes, and I'm not suggesting you use it.  It was simply to
>illustrate that there is another method of doing things, and what the
>original problems were.  (A good solution to the Animals 'problem'
>would be simple, it just wouldn't demonstrate any of the things you
>want to show.)

Then it wouldn't be a good solution.  What I want to show is at least
one of every structure needed in a real program.

I've made your example one of the exercises.  It solves a particular
problem, and it is worth showing.

>> We also need to make sure we include *all* children of Reptile in the
>> new numReptiles function.
>> 
>> class Reptile(Animal):
>>    -numReptiles = 0
>>    def numReptiles():
>>       return ( Reptile._numReptiles +
>>          Snake.numSnakes() + Lizard.numLizards() )
>> 
>> Oops.  We forgot Geckos !!
>> 
>> To avoid these errors in programming, we may need a function that
>> automatically searches for subclasses, and calls their num functions.
>> I'm not sure how to do this without making it excessively complex.
>> Suggestions will be appreciated.
>> 
>> -- Dave
>
>Hmm, I think perhaps I like your original example better than this.
>:-\   It's a bit like treating a cut throat with a tourniquet.
>
>Searching the subclasses will AFAIK still require some kind of
>metaprogramming, which is not too suitable for a 4-hour beginner
>course on OO.

Most likely, we will not cover the solutions to the maintainability
problems, but we will mention them so students are aware.  Electronic
design engineers are good at structured, hierarchical, robust design,
so I won't have to spend a lot of time on encapsulation, modularity,
maintainability, etc.  They are well aware of the need for protection
circuits on all inputs.  Pointing out the problems in a simplified
program example should be sufficient.

-- Dave