--On 18. April 2007 16:31:29 -0700 Christopher Lozinski <lozinski@freerecruiting.com> wrote:
AND HERE IS THE REAL ISSUE I THINK 7. Because of the way Zope is written, you just cannot do ZClasses "right". You would have to change zope, and break lots of things. I think that is the core reason that some people say ZClasses are dead. I am just starting to understand it. I have been digging into the core of Zope. I keep excavating lower than I have ever excavated before. I would like to make a tree of classes, just like in the smalltalk browsers. Zope Products manager or whatever it is called does not like that. I would like a ZClass to have a subobject for every instance variable, and for that instance variable to say which role can read, and write it, independent of where you are in the ZODB tree. Not quite how Zope permissions work. So I think the structure of Zope prevents ZClasses from working correctly. Which is why ZClasses needs to die. Is that correct?
Because to change the core of Zope is way too heretical. Better for ZClasses to die, than to change the core of Zope 2.
Why should be change the core of Zope 2 just to making ZClasses work better with *the risk* to break Zope 2 backward-compatibility? Backward-compatibility is nowadays the *most important* point when performing changes in the Zope 2 core. Just for this reason: forget it Better go with Zope 3 which is definitely more flexible when it comes to configuration and composition of components. Since you're on the siding with your personal implementations it does not mean that we have to change the core (just because you need it). Patches, improvements etc. that improve the ZClasses situation and that are compatible with older versions are of course always highly appreciated. But please: come up with *something*...don't except that the solution for your particular problems falls from the sky (or comes from one of the Zope 2 core developers)...it's time for personal efforts. Andreas