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