Unification of Methods and Functions

[David MacQuigg]

On Fri, 14 May 2004 14:25:15 +1200, Greg Ewing
<greg at cosc.canterbury.ac.nz> wrote:

>David MacQuigg wrote:
>> 1) We need to represent a hierarchy of cells, typically 5 to 10 levels
>> deep.
>> 2) Each cell has data associated with it.  Some of this data is a
>> cummulative total of similar data from all subcells -- total currents,
>> total chip area, etc.
>> 3) The data for each cell is unique, and it must be displayed in a
>> format unique to that cell.
>> 4) We need a simple function, show() that can be called for any cell
>> or no cell at all (just knowing the cell type).  This function should
>> show the cell data and the data from all cells above it.  In case no
>> cells of a particular type have been added to the design, the
>> cummulative data should just show a default value, like zero.
>
>It's still not clear whether the hierarchy you're talking
>about is a hierarchy of *kinds* of cells (i.e. a class
>hierarchy), or a physical hierarchy of actual cells (i.e.
>an instance hierarchy).

In the Animals_2 example we are discussing
http://ece.arizona.edu/~edatools/Python/Animals.py, the classes (
Animal, Mammal, Feline, Cat ) are *kinds* of animals.  The instances (
cat1, cat2, etc. ) represent the actual objects in the inventory.

James has been telling me it is terribly wrong to keep data as
attributes of classes, or to make the methods in each class dependent
on superclasses.  The latest suggestion (if I understand it correctly)
is to make a dummy instance from each class, just so we can store data
that is common to the whole class.  The "functional spec" above
deliberately avoids any requirement for classes, instances, other
implementation detail.

I'm still trying to come up with a simple example using James' latest
suggestions (something simpler than the automatic class generator he
wrote).

class Feline(Mammal):
    _numFelines = 0
    genus = "feline"
    def __init__(self):
        Mammal.__init__(self)
        Feline._numFelines += 1
    def show(self):
        Mammal.show(self)
        print " Felines:", Feline._numFelines
##    show = staticmethod(show)
feline = Feline()

By adding an extra line after each class, we can eliminate the static
methods.  Now when I want to show the characteristics of the Feline
class, I can call feline.show() and get the same result as I had
before using the static method Feline.show().

I still need to move the data to the instance, and get rid of the
super calls ( Mammal.__init__ and Mammal.__show__ )  I am having great
difficulty understanding James' suggestions.  Maybe you could help
clarify what is wrong with the original example, and what we need to
do to fix it.

>Both of these hierarchies can exist at the same time, and
>they are different.

This is true, and the real program will be more complex than the
Animals_2 example.  In Animals_2 it is sufficient to know the total
number of Cats.  In the real program, we will need the total number of
gates of type NAND2.  In *addition*, we will need to know the total
current to each instance of NAND2, including all the subcircuits under
that instance.  Those totals, in my way of thinking, should be stored
on each NAND2 instance.

>For example, you might have a kind of cell called NandGate,
>and a kind of cell called Transistor. An instance of NandGate
>contains instances of Transistor -- this is an instance
>hierarchy. But Transistor is not a subclass of NandGate --
>that would imply a Transistor is a kind of NandGate, which
>is not true.
>
>On the other hand, NandGate may well be a subclass of Gate,
>and Gate and Transistor may be subclasses of Component. But
>that doesn't mean Gates *contain* NandGates.
>
>If prototype-based programming leads to confusion between
>class hierarchies and instance hierarchies, the I would
>say it's not helpful.

Let's make sure we are talking about the same thing.  If by
prototype-based programming, you mean Prothon-style, classless
prototypes, then I agree.  The benefits of having a distinction
between classes and instances, in my current understanding of
"classless programming", far outweigh any simplification that might
flow from having just one "tier" in the object model.  That is why I
have avoided in my proposal the "classless" aspects of Prothon.

On the other hand, if you are suggesting that something in my current
proposal will lead to confusion, I would like more specifics.

-- Dave