Python evangelists unite!

[Jyrinx]

> > > For example, I'm writing a Ruby binding to the Object-Oriented
> > > database GOODS.  Some objects are persistent, some are transient.  You
> > > don't know at "compile time" which are which, so it's very nice for my
> > > binding to be able to add persistence support methods at run-time only
> > > to those objects that will be stored in the database.  Without Ruby's
> > > support for adding these methods to individual objects, I'd have to
> > > modify the class, which would mean adding all this persistence-related
> > > stuff to transient objects.  Ruby allows a much cleaner solution: add
> > > the persistence support methods only to those objects that need them.
> >
> > Under the basic premises of OO, shouldn't you just have a base class
with
> > derived classes "persistent" and "transient," or some such? I'd think
this
> > would make clearer your intent for the uses of the objects.
>
> The problem with this is that it defeats the idea of transparent
> persistence.  One goal of object databases is that persistence is not
> limited to a subset of the class heirarchy.

Okay, I can see that. In other words, the hierarchy should express the
relationships between objects, not a particular feature of certain objects?

> ...
> Some OO databases ignore this and force applications to use
> "Persistent" superclasses or interfaces.  IMO, this is a very bad
> idea.  Consider that you may have a million instances of a class, only
> one of which is persistent (by the reachability definition).  If the
> class has to subclass a "Persistent" class, all of those million
> objects have to carry around the Persistence baggage, even though only
> one of those objects needs them.

I thought only the persistent objects would subclass the Persistent class;
how does the persistence baggage get into objects of classes derived from
Transient? Wouldn't only leaves, so to speak, of the hierarchy derive from
Persistent or Transient anyway?

> Adding the persistence baggage to individual objects as necessary
> provides a much simpler and scalable solution.  Simpler because
> application developers don't have to bother with subclassing (or
> implementing) a Persistent class (or interface).  More scalable
> because the persistence support is added to *only* those objects (not
> classes) that need it.

I'm not sure how the singleton stuff is more scalable (though I'm sure you
have more experience than me). Hypothetically (yeah, I'm on shaky ground
here), what if you had more than one major behavior (besides just
persistence) that might vary between objects of a given class? Mightn't it
get messy to keep track of which objects are which? (I suppose, though, you
don't have to "keep track" of which ones are persistent; they just act
differently.) I wonder if it wouldn't really be clearer just to declare
trivial classes which inherit multiply from Persistent/Transient, other
behavior implementations, and other parent classes. (Of course, in Python
there's no such thing as a trivial subclass definition; you've got to
overload __init__ specifically and call __init__'s in each base class. This
ticks me off to no end.)

Also, a more technical concern: shouldn't every Ruby object need hooks in
place so that any single method could be overridden in individual objects?
I'm envisioning a class instance with a function pointer for each method ...
that's a nasty thought. Or does each object carry a list of overridden
methods, to be checked with each method call? Isn't there significant
overhead either way? Or (most likely) is it implemented in too clever a way
for me to come up with? :-)

Jyrinx
jyrinx at mindspring dot com