pcplantdb

[Chad Knepp <pyg@galatea.org>]

John Schinnerer writes:
 > Aloha,
 > 
 > Chad, thanks for posting the zope site article on OO design.  Hadn't 
 > seen that one myself and it was well and clearly written - hopefully 
 > clarifies some of my early ramblings about why IMO OO is the way to go 
 > for what we're trying to do - model complex objects and their interactions!
 > 
 > Rich brought up the question of what objects we need...
 > My very brief response is basically what the article says about OO 
 > design...one starts with the most basic elements - ideally common to 
 > most everything we'd eventually create - and creates a base class 
 > (simplest objects we'll have).  There may be a couple of these, not 
 > necessarily just one.

<techie rant> Yes, I was planning on a base class that pretty much
every object in ZODB would inherit from.  Some other structural ideas
I've had is that I would like to put most/all the objects in one
IOBTree ({'Integer': 'Object'} Balanced Tree).  Every Object will have
an Integer key/id.  There could be Object keys, but I can't see the
need and I suspect Integer keys will perform better.  One tricky thing
though is creating unique integers for all the objects.  My solution
so far is to use a persistent generator function
<http://python.org/doc/current/tut/node11.html#SECTION00111000000000000000000>.
ack! uses a kind of primitive counter that I doubt is thread
safe... possible to have data loss at high levels of object creation
in multiple concurrent connections.  Anway, the base class __init__
would call this generator function to get it's object id, assuring
safe unique ids. </techie rant>

There will also be Zope application objects that will somewhat
seperate from the stuff in ZODB.

 > So what attributes (data) and methods (code) are most fundamental to 
 > what we're doing?
 > Should we have a wiki page for tracking this thread...?
 > Chad, have you already got a working idea of where to start here?
 > If so pass it around, let's see what the rest of us make of it.

Plant objects are pretty obvious, at least the attributes.  I will
submit an attribute proposal based on our current dataset for comments
in the very near future.  After it stabilizes it would probably be a
good wiki page. I would like to be on the side of having attributes we
don't ever use than having to add them later although I suspect we
will certainly need to tweak something later on.  Anyway it already
seems easier than trying to change the schema in an RDBMS.

 > Anyhow...from there on, the base classes (the "blueprints" for our 
 > simplest essential and necessary objects, which contain attributes and 
 > methods we think will be common to all our objects) are used to build 
 > more complex classes, which can then themselves be used to build yet 
 > more complex classes, and so on...and so on...and so on... :-)

class HGObject ():
    "Base class"

class Comment (HGObject):
    "Inherits HGObject"

class Article (Comment):
    "Like a comment but with more features"
    "Inherits Comment which inherits HGObject and so on..."

An interesting thing in my experience of OO programing is that I don't
usually write base classes in their entirety right away.  Actual
development of the classes is almost parallel and I often realize that
something in a subclass (the more complex class) could actually be
generalized and should be in the superclass (the base class).

-- 
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'