[Zope-dev] TransWarp preview release (AOP tools only)

[Shane Hathaway]

"Phillip J. Eby" wrote:
> 
> At 10:52 AM 3/6/01 -0500, Shane Hathaway wrote:
> >Perhaps... but as I see it, pickling the aspect weaving information into
> >each object makes it harder to vary the aspect weaving after objects
> >have been created.
> 
> That's not what I said.  *Aspect objects* can be pickled.  You're talking
> about *instances* of *classes* created by weaving the aspects, and that's a
> whole different kettle of fish.  Check out the "AOPTutorial" in the Wiki,
> which sorts out the differences between the three.

I understand.  What I'm saying is that for this application, sys.modules
will not contain the information necessary for reassembling the
aspects.  So you have to either put that information in the pickled
objects or in a centralized pickled object.  I thought you had suggested
putting the information in the pickled objects and we agree that is
probably not the right approach.  Instead the objects will contain a
reference to a centralized pickled object that can supply the weaving
information.  I know I'm not using perfect terminology.

> >I'm also planning outside the ZODB.  The goal is to design apps using
> >pure and simple ZODB and not be required to do anything special to make
> >it work later with other forms of storage.  Other databases will not be
> >able to store aspect information.
> 
> Again, this is a confusion of instance and class.  Aspect information is
> *not* per-instance - heck, even *classes* in TW don't know what Aspects
> they were woven from.  The aspects are like flour and eggs that go into
> making a cake (class or set of classes).  Once it's baked, the ingredients
> are no longer visible.  :)

ZODB creates two pickles for every object: the class of the object and
the object state.  One could conceivably store the aspect weaving
information in that first pickle.  (Normally the first pickle is very
simple, containing only the name of the module and the name of the
class, but it can in fact be as complex as you want.)  In fact,
depending on how you coded TW, that's just what ZODB might try to do and
it might even work.  But for this application I wouldn't want it to do
that.

BTW in Python, classes are really just instances of class classes (or
type classes, or class types, or class class classes etc...) ;-)

> By the way, I have never tried to promote AOP as even being relevant to the
> CMF.  :)

I know.  I'm justing trying to "weave" your work in to Zope.

> AOP is mostly about *reuse*, so any single run-time environment
> (such as CMF or even Zope as a whole) will not see much benefit that you
> can't get through delegation.  ZPatterns, for another example, is one
> gigantic web of delegation internally.  AOP is of more relevance to the
> developer who has a piece of code they would like to use for the CMF, *and*
> for a command line tool, *and* a testing tool, *and*....  And thus they
> need to be able to assemble their code into a variety of useful
> configurations.

I see.  I'll try to keep that in the back of my mind.

> After Michel's presentation the other day, I understand a lot better how
> Zope will address this issue with "adapters", and that will help *a lot*
> with a lot of things.  However, people may also have other environments
> besides Zope to use their code in, or other configuration choices to be
> addressed that are not exposed to Zope (such as the database schema), and
> having AOP available will presumably be helpful to them.

Agreed (though I've been working on a delegation-capable storage...) :-)

Shane