[Zope-dev] Changing ZClass base classes comfortably (was Warning! TransparentFolders...)

[Phillip J. Eby]

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!