Unification of Methods and Functions

[Greg Ewing]

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

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

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.

-- 
Greg Ewing, Computer Science Dept,
University of Canterbury,	
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg