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

[Phillip J. Eby]

At 09:37 AM 3/1/01 -0500, Shane Hathaway wrote:
>This looks very interesting, Phillip.  I haven't downloaded the package
>yet, but I read the wiki and it finally made sense once I understood the
>goal (I think): TW lets you set up the class inheritance hierarchy at
>runtime.  In normal OO methodology, you can only extend classes.  With
>TW, you can also slip your own version of a base class into a class
>hierarchy (without actually modifying the Python class hierarchy, of
>course.)

That's a good way of describing the *function* of the AOP part of
TransWarp.  The goal is not so much to set up the inheritance hierarchy at
runtime, as to allow you to configure various versions of the same
component, and to write seperately-managed "aspects" for different areas of
concern.  The targeted time is not really "runtime" so much as "build
time".  Runtime is a side-effect of how it's done, and it can be useful for
things like selecting an OS-specific or other environment-sensitive aspect
at application startup.  But the main goals of the AOP portion are being
able to instantiate customized versions of "third-party" components, and to
be able to mix-and-match implementations for different areas of concern.
For example, wxPython vs. Tkinter vs. Win32, SQL vs LDAP vs ZODB, and so on.

TransWarp in the larger picture will also deal with generative programming;
the UML-driven parts will generate aspects that contain structural
information (inheritance, associations, aggregations, attributes, etc.)
that can then be merged with non-structural aspects.  The ability to "set
up the class inheritance hierarchy at runtime" provided by the AOP tools
will then allow you to define what an "attribute" is, and give it
publishability, security permissions, or a GUI rendering.

There is actually code in the preview release to do this structural
generation for the UML metamodel (if loaded from MMX format), and it's even
rudimentarily tested (one unit test that just makes sure it doesn't blow up
altogether) but the "StructuralModel" aspects that implement attributes and
associations are currently broken, not yet updated for the true AOP model.
Earlier versions of TransWarp did class generation as an integral part of
the GP system, not as a GP+AOP system, and I'm still adapting a lot of
stuff to take advantage of AOP and to use a cleaner metadata mechanism.


>What is your vision of integrating AOP into a persistent object system? 
>Would one drop in an object that modifies the class loading mechanism so
>that the classes come from a TW component rather than Python modules?

Not necessary.  If you dig into the TransWarpFAQ page in the Wiki, you'll
see a question that explains how to make TW-generated classes work with
pickle and cPickle.  It just requires one additional argument at
aspect-weaving time, to specify the module which the generated classes
should be registered with.  This means that TW's AOP features are
functional right now, today, with ZODB.  (As long as the classes are
generated in good ol' Python module files.)

Now, as to whether TW will be fully compatible with Zope 3 "persistent
modules", that's a different question.  In the conversation I had with Jim
in January, based on his description of the module refresh mechanism and of
import proxies, I would say that TW-generated classes would not properly
refresh when a persistent module that they were dependent on changed.
(Because TW will generate new class objects from the imported classes
rather than referencing them via the proxy.)  But that's based on a very
early notion of how Z3 persistent modules would work.

One reason I've been racing like mad to get the preview release out is so
that, after seeing the usefulness of TW for the Zope 3 component
architecture, y'all might be interested in considering implementations for
module persistence besides proxying.  :)  IMHO, a "rollback importer"
approach ala unittest might be better suited for TW-ish components, and
have fewer weird side effects for persistent modules generally.  I don't
like unittest's mechanism for *doing* the rollback, and Zope would need a
thread-specific version of sys.modules, as well as a mechanism to purge the
cache of any objects which were loaded after any of the purged modules, but
I think the basic idea is sound.