[TransWarp] lifting class families into Zope

[Daniel Mahler]

Phillip J. Eby writes:
 > At 04:59 PM 1/17/03 -0600, Daniel Mahler wrote:
 > 
 > >I wonder if TransWarp/PEAK offers any way
 > >to automate the problem of Zopefying preexisting a class library.
 > 
 > Actually, if I understand Zope 3 correctly, it should be possible to do 
 > this without modifying your source code, apart from perhaps the need to 
 > inherit from the Persistent base class.  Everything else should be
 > doable 

That sounds great.

 > with adapters, and not having to replace your classes.  But of course, 
 > that's Zope 3, and perhaps you're talking about earlier Zope versions.

Depends on where on the event horizon a production stabe Zope3 is.

  [...]
 > You may want to see if PEAK's module inheritance function does what you 
 > want.  It lets you create a module that "inherits" all the existing classes 
 > defined in another module, and then mix in additional code to any of the 
 > classes.  All functions and methods in the original module are rebound to 
 > the globals of the new module, so references to classes in the old module 
 > will refer to to the new classes in the new module.
 > 
 > All you do is add "config.setupModule()" calls to the end of the "old" and 
 > "new" modules, and in the "new" module, you add code like this:
 > 
 > import oldmodule
 > __bases__ = oldmodule,
 > 
 > to the top.  Then, if you want to mix something into oldmodule.Animal, just do:
 > 
 > class Animal(StuffToMixIn):
 >      pass
 > 
 > And finish off the module with:
 > 
 > from peak.api import config
 > config.setupModule()
 > 
 > That's it.  "newmodule.Dog" will now be a different class than 
 > "oldmodule.Dog", and its "newmodule.Animal" base will inherit from 
 > StuffToMixIn.  PEAK recreates the entire class hierarchy for you, with all 
 > new mixins or functions mixed in.
 > 
 > See "peak.config.modules" for docs, and the peak.config.tests module for 
 > more examples.
 > 

This sounds very much like what I have in mind.
Will newmodule.Dog().liver return newmodule.Liver
or oldmodule.Liver.
(I expect that the answer is
"that depends on how you initialize the liver attribute",
but I thought I would ask anyway)

D