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.