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

[Phillip J. Eby]

At 10:52 AM 3/6/01 -0500, Shane Hathaway wrote:
>"Phillip J. Eby" wrote:
>> 
>> There's actually a simpler way.  Aspect objects can be pickled as long as
>> all the objects in them can be pickled.  Which means that as long as all
>> their methods are Zope objects, and all the nested classes are also Aspect
>> objects, you can save an aspect into the ZODB, and load it at a future
>> time.  Further, since adding aspects together makes new aspects, you can
>> save the combined aspects, so you only have to perform one call to
>> transform the aspect into a family of classes.  That still means some
>> load-time complexity, however.
>
>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 would want to be able to create a portal, add some
>content, then change the aspects that apply to the content after it has
>been created.

Of course, just as you can currently upgrade a class that has instances in
the ZODB.  Regenerating the class from different aspects would have exactly
the same pros and cons as upgrading a .py module containing a class that's
used in the ZODB.


>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.  :)


>That's actually the kind of functionality we have now, but we're using
>subobjects rather than tabs and we achieve many of the things AOP would
>give us through simple delegation.  You should check out the CMF as soon
>as the beta is released.

One of the interesting things I learned at the Python conference this year
(through some of the papers, like the Virtual Worlds and Thin Client
projects) was where the best trade-offs between a delegation approach and
an AOP-style approach are.  The spectrum seems to be that if your instances
need to make lots of different choices, or if they need to be able to add
and remove aspects on an ongoing basis, then some type of delegation is
probably the way to go.  If your choices are more about *configuration*
that applies to *multiple classes*, then aspects are probably more
appropriate.

By the way, I have never tried to promote AOP as even being relevant to the
CMF.  :)  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.

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.