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.