[Zope3-dev] persistence by adaptation, and aop?

[Guido van Rossum]

> In jon udell's latest column, he notices a pattern in several flavors
> of java object persistence mechanisms - an aspect-oriented programming
> characterization.  It got me to thinking about how we continue to do
> persistence as a mixin for objects, and wondering whether we could do
> it with our alternative to AOP, adapters...  I don't know enough about
> components' innards to judge, and am wondering what those i in the
> know think of the idea?
> 
> The article is at:
> 
>   http://www.infoworld.com/article/03/05/30/22OPstrategic_1.html 
> 
> The article is short, but it's still worth repeating a single
> paragraph which sums up the observation:
> 
>   For object or relational databases, simple objects, and EJBs, the
>   same underlying technique has been used to achieve persistence. When
>   I see a repeating pattern, I listen to what it's telling me. In this
>   case, the message has little to do with the practice of hacking Java
>   bytecodes and everything to do with an emerging discipline called
>   AOP (aspect-oriented programming). Seen through the AOP lens,
>   persistence is something you declare about an object, not something
>   intrinsic to it. The "managed" middleware environments (J2EE, COM+)
>   take a similarly declarative approach, as do the new breed of Web
>   services management solutions. AOP is crossing from theory to
>   practice, but it's a profoundly unifying idea that will resonate
>   throughout the industry.
> 
> (I may be off base comparing the component approach with aspect
> oriented programming.  I strongly suspect, though, that they address
> the same purpose.  That purpose is something like packaging
> functionality so it can be conveyed to any situation where it is
> useful without being locked in with other, independent functionality.
> And form the little i've seen of AOP approaches, components seem to me
> to encapsulate the extensibility in way that's much more congruent
> with the rest of OOP...)

Nice find.

Pickling is certainly a problem that looks like it would be better
solved with adapters than with the current mixture of hard-coded
knowledge (like the Pickler class) and special methods added to
classes (__getstate__ etc.).

I don't know how adapters relate to AOP though.

One think to note is that he claims that persistence is declared about
an *object* -- not a class.  Adapters are still about classes.

Another thing to ponder is that for pickling, inheriting the pickling
implementation (unless it's truly generic and uses introspection to
find all instance variables) isn't necessarily the right thing to do.
Again, adapters don't really help with this.

--Guido van Rossum (home page: http://www.python.org/~guido/)