[Zope-dev] Two glaring omissions

[Shane Hathaway]

Alexander Limi wrote:
> I've been working with Zope for almost two years now, and there are two
> things that I feel is missing in the interface:
> 
> 1. The ability to add a Base class after the class is created

This is a feature we'd like to have, but the way ZClasses work currently
makes it dangerous.  What gets pickled in the ZODB isn't information
about the class, it's the class itself.  In order to change bases
safely, you'd have to try to reverse-engineer the original parameters
for creating the class object as well as all changes made afterward,
then modify the parameters slightly and construct a new class.  That's
what the published hack essentially does.

Another pitfall of storing the class itself in the ZODB is that if any
of the bases disappear, the ZClass can no longer be loaded.

If these two issues are important enough, we have a good reason to
consider a new kind of ZClass.  With "lightweight" ZClasses, class data
would be stored in a meta-class object.  The meta-class would construct
the class instance.  Changes bases and failing gracefully when a base
disappears should be easy.

The part that may still be hard is getting object instances to sync up
with the ZClass immediately when the user has changed the ZClass. 
ZClasses are good at that, you see.

> 2. The ability to rename properties after instances of the classes have
>    been created (and have the data in those fields preserved)

This is also more difficult than it sounds.  You'd have to either scan
through the entire ZODB and modify class instances or associate
properties with a magical, unchanging ID.  The latter solution is dead
wrong, but the first is actually kind of interesting.  If there were a
separate index for each object type in the ZODB, it would be possible. 
In fact, when ZODB is running from a relational database, there is
indeed a way to do that.  Hmmm...

Not that I have the time to work on these things.  I'm swamped.  Anyone
want to draft a proposal?

Shane