At 03:44 PM 5/4/00 -0400, Kevin Dangoor wrote:
Does anyone know what exactly the potential issue is with the hold-on-to-the-seat-of-your-pants method of base class changing? I know lots of people have done it without trouble... but, I bet a lot of people would prefer Zope had a more "supported" method of doing this through the web.
The ZClass machinery uses several levels of metaclasses which are created at the time of setting the base classes. Unlike a Python class which is recreated when you edit the code, you are dealing with changing a class which has instance data (so to speak). And not just one, but at least *three* such classes, namely the class itself, its runtime propertysheets class, and its editing class. Each of these has dependencies on the original base class, not to mention data strucure issues for permissions and other Zope framework items. This is why the _setBasesHoldOnToYourButts() method creates a brand new ZClass to replace itself, then copies everything into it that was in the original class. Now, I'm not aware of any problems that *will* be caused by changing bases... but I have studied some bits of the ZClass code (and have even written code that "implements the notional subclassable propertysheets class interface") and let's just say if it makes Jim worried, it should make the rest of us even more so. :) Side note: Ty and I used to joke about this crazy ZClass variable called "_implements_the_notional_subclassable_propertysheets_class_interface"... until we found out what it actually *does*, and why we needed to use it in the ZPatterns framework to give objects pluggable propertysheets. And upon understanding it (and the other ZClass wizardry we discovered but have not exploited yet), our level of respect for the Zen of Master Fulton went up yet another notch. :) Anyway, so like I said, in this context, if Jim's worried about it, I'm *really* worried about it!