Component Racks

[Terry Hancock]

Hi all,

I'm trying out an "interface/component/rack" model for handling
3rd party code in my current project, and I've run into a design
question which seems to hinge on the internal design of Python
(namely how efficient is the name/binding model compared to
a variable/contents model).

Basically, each "component" is a class (possibly all different,
but each implementing a single "interface").  The "rack" is a
PersistentMapping (which is in turn a subclass of UserDict). So,
you can just access components through the rack, like so:

Diner['spam'].eat()

Where 'spam' is the component's key.

So far, so good.

Now when I register this component into the rack (or should I
say "plug"?), I collect a number of pieces of meta data that I might
want to access -- such as a "label" or "key", a longer descriptive "name",
and an small graphical "icon", all of which are used in the user
interface when representing access to this object.

Where should that meta data be stored?

Intuition from some other languages would suggest that that 
(very lightweight data) ought to be in a separate data structure
to avoid performance problems with accessing the full blown
class objects.  But, since Python just slings around name references
to objects, I wonder if I'd be safe just including the meta-data in
the actual objects:

In other words, I just modify the component object to contain
the necessary meta data:

class SpamComponent:
    __implements__ = SpamAPI
    label = 'spam'
    name = 'Spam'
    title = 'Yummy, yummy spam'
    icon  = 'Icon/spam16x16_png'
    def eat(self):
        pass
    # ... etc ..., possibly large and complex class

Basically, my question is, should I be worrying about memory
access problems if I have a lot of these components and I have
a lot of objects that need to get, say, the "icon" and "label" without
needing the whole object (i.e. will those kinds of simple accesses
be slow compared to fetching them from a dictionary of simpler
SpamComponentPlug objects).

Now, having said all that in a pure Python context, does it matter
if the "full-blown-class" is a persistent data object in a ZODB (i.e.
a Zope object)?  As I currently have it, the SpamComponentPlug object
is *not* a persistent object in itself (but it's stored in a 
PersistentMapping, so that may have the same effect).

Obviously, the disadvantage to this seperate SpamComponentPlug
object is that it's *one more object* to keep track of.  It requires the
call above to read like this:

Diner['spam'].actual_object.eat()

(i.e. I have to make an extra indirection step -- from the
SpamComponentPlug to the SpamComponent).  I'd like to eliminate
that step.  But I've managed to really confuse myself about what
impact this will have on performance (memory consumption,
relative speed, etc.).  Would the size of the SpamComponent
class definition have any effect on performance?

Thanks for any illumination,
Terry

-- 
Terry Hancock
Anansi Spaceworks http://www.AnansiSpaceworks.com/