Unification of Methods and Functions

[James Moughan]

> >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.
> """

This wouldn't quite be my position, though.  It doesn't hurt to have
changable data in a class; it's a question of what happens when you
loose the locality of that data, especially in terms of debugging
effort.

Quite likely I have not always communicated myself to you perfectly. I
see how someone could ignore the word heirarchy in the above quote and
loose most of the meaning, which was that data should generally not be
distributed throughout the class heirarchy as if it were a data
structure.

However, I had thought by now that I had made it clear that I do not
regard it as "terribly wrong to keep data as attributes of classes";

2004-05-10: "...you should think carefully before using classes to
store data"

"2004-05-10": "we want to keep the data stored in each class local to
that
class.  So, Mammal can store the number of Mammals, if that turns out
to be a good solution..."

So I am not sure why you would misrepresent my position so thoroughly.

> 
> 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.
> 

And I would have argued no;

1) I'm not sure why this example is simpler than any other
singly-inherited heirarchy.  IMO the way it works makes it more
complex than most I've seen.
2) If there's one thing you can rely on, it's people making mistakes,
especially the simple ones.  Making a program easy to debug in the
face of simple mistakes is IMO an extremely good idea.
3) That's not especially relevant to what I've been talking about,
that is, programmer error and debugging.
4) Whatever you teach students the first time round takes a long, long
time to leave their heads, if it ever does.  Picking practically and
theoretically sound examples would not be hard.  These do not have to
be complex at all, just simple examples of typical uses of class
heirarchies.


> 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

Simple method - choose a different example.  However, you do not
appear to be open to this suggestion.