Python evangelists unite!

[Jason Voegele]

"Jyrinx" <jyrinx at mindspring dot com> wrote in message news:<9ufdth$155$1 at slb5.atl.mindspring.net>...
> > 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.  This goal forbids a
superclass as an indicator of persistence-capability.  Instead,
persistence is define by reachability: if an object (any object!) is
reachable from a persistent object, that object becomes persistent
itself, as well as any objects reachable from that object...and so on.

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.

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.

Jason Voegele