Unification of Methods and Functions

[David MacQuigg]

On 18 May 2004 17:00:12 -0700, moughanj at tcd.ie (James Moughan) wrote:

>David MacQuigg <dmq at gain.com> wrote in message news:<gtoja0h3jub75ocnr7da8ho8i5lpihc432 at 4ax.com>...
>> On Mon, 17 May 2004 16:40:00 +1200, Greg Ewing
>> <greg at cosc.canterbury.ac.nz> wrote:
>> 
>> >David MacQuigg wrote:
>> >> James has been telling me it is terribly wrong to keep data as
>> >> attributes of classes
>> >
>[snip]
>> 
>> This makes a lot more sense than a total ban on data in classes.
>> 
>
>Just to clarify, once again - I was not suggesting a ban on data in
>classes - I was objecting to the specific way in which the data was
>being passed around and used in the class heirarchy.

You have some good ideas, but you have been making extreme statements
and over-generalizing.
"""
5/17/04:
OK: "The whole idea of having these structures in any program is
wrong."

Firstly, the program uses a class hierarchy as a data structure.  That
isn't what class heirarchies are designed for, and not how they should
be used IMO. But it's what any bright student will pick up from the
example.
"""

We could avoid a lot of non-productive discussion if you were more
careful with these statements.  Instead of the above, you could say:
"""
Generally, its not a good idea to store *changeable* data in the class
itself.  The Animals_2 program has variables like _numAnimals, which
change when any instances of subclasses are created.  If this were a
much bigger program with hundreds of classes being implemented by many
different programmers, one of those programmers might forget to add a
call to the parent's __init__, and all counts of classes above the new
class would be wrong.
"""

Then we could have a productive discussion on whether, in this case,
_numAnimals is OK.  I would argue yes, but I understand your point
about the possibility of new, incorrectly written classes causing a
problem.

The reasons I would argue yes are:
1) This is a very simple hierarchy, even if it grows to a hundred
classes.
2) The incrementing of the _num... variables is a simple and standard
part of every __init__ in this hierarchy.  A programmer who would
ignore that, is a programmer who would completely mess up modification
of a more complex program involving automatic generation of classes.
3) This is not a database or transaction processing system that needs
to stay online for days at a time, and is vulnerable to out-of-sync
problems arising from interupted sessions, etc.
4) This is an example for students who are new to OOP. I would rather
keep the example simple, and point out how it might be improved, than
burden the students with all the details of a production-quality
program.

I've made your program, Animals_JM.py at
http://ece.arizona.edu/~edatools/Python/Exercises/ the next example
*after* Animals_2.  The topic of techniques to make a program robust
and maintainable is worth a whole chapter, but it would be a
distraction in the introductory chapter.

I would still like to see a way to gain the benefits of both Animals_2
and Animals_JM in one program.  My attempts to follow up on
suggestions in this discussion have only added complexity, not
improved the program.

-- Dave