Unification of Methods and Functions

[David MacQuigg]

On 17 May 2004 12:35:23 -0700, corey.coughlin at attbi.com (Corey
Coughlin) wrote:

>You know, it's interesting, I'm an engineer at a semiconductor
>company, and I've written netlist manipulation objects over and over
>again with only the most basic oop structure, and they usually work
>fine.  Associating data with each cell is usually not that hard,
>although the show() function showing data from all cells above it (?)
>seems kind of strange.  This type of problem is a case where object
>encapsulation is usually a lot more effective than inheritance.  In my
>netlist objects, the most basic object is just a name object, which
>everything inherits because everything in a netlist has a name. 
>Beyond that, there's some container inheritance, I came up with an
>ordered dictionary for pin data, some simple inheritance where Pin
>objects inherit from Net objects, but that's about it.
>
>The basic object structure is pretty simple.  The highest level object
>is a netlist.  The netlist contains a list (just a simple python list)
>of cell objects.  The cell objects contain a list of nets, a list of
>pins, and a list of instances.  There are classes for instances, nets,
>and pins (which inherit from nets).  The instances do refer to their
>parent cells, and the pins from the parent are copied in, but that's
>about as complicated as things get in the class hierarchy.  There's
>also a special container class to describe the connections in a cell,
>so I can send the connection mesh a net, an instance, or an
>instance,pin tuple, and find out what it's connected to.  That's
>probably the most complicated class, since it uses a few internal
>dicts and a type driven interface to resolve the input data.  But
>that's really about the size of it.  Transistors would be instances in
>cells (although a transistor cell parent is also in there) and gates
>would simply be cells.  Now if you had similar cells with different
>current or power characteristics, I suppose you'd need to associate
>those with an instance class instead of a cell class.  Beyond that, I
>don't really see why this is such a difficult thing to do.  Unless
>there's some other overriding goal this needs to accomplish that isn't
>in the spec below.  You might want to try just coming up with
>something like the container hierarchy I have, not worrying about
>inheritance, and see if that does the trick for you.

This is the kind of thinking I like.  90% of what we need to do can be
done with the simplest of programming constructs.  I know your company
probably considers what you develop proprietary, but would it be
possible for you to contribute an example suitable for teaching OOP to
EE students?

I will probably still keep the Animals example in the intro, since it
shows almost everything we will ever need in the simplest possible
structure.  A netlister would be a great example, however, especially
since my students are studying EDA tools.

-- Dave