Of course all those points can be done in python, im assuming you are talking about ZClasses. -- Andy McKay, Developer. ActiveState. ----- Original Message ----- From: "Alexander Limi" <alexander@mp3.no> To: <zope-dev@zope.org> Sent: Tuesday, November 14, 2000 11:35 AM Subject: [Zope-dev] Two glaring omissions

Hi,

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

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

Are there any technical reasons why these are not present? I know it is possible to add base classes in retrospect via the hack described in

http://www.zope.org/Members/AlexR/ChangingBaseClasses

but are there plans for making this easier?

As for #2, it is quite annoying and counter-productive not being able to change a variable name that was decided a long time ago, or maybe by others simply because there exist instantiated objects of that type.

Both of the above are pretty essential OO techniques (for me, at least), and hinder my work quite a lot by not being there.

Any chance of these being fixed at all? Or are there reasons that I do not know about that makes this impossible?

Regards,

-- Alexander Limi alexander@mp3.no

_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )

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