TransWarpFAQ

The TransWarp FAQ

Got a question you don't see here? Add a comment or drop us a line!

Basic/Informational Questions

When will I be able to do AOP with TransWarp?

You can start today! Just download the preview release.

When will I be able to do GP and CASE with TransWarp?

Not quite so soon. Getting a cleanly defined API for ServicesElementsAndFeatures was more of a headache than we expected. The earlier iterations of TransWarp's UML and XMI packages had a really ugly API on the generated Element and Feature classes. There were a lot of concepts that wound up in there from the NovoSoft UML library, and those concepts didn't scale well once we realized we were making a general GP tool and not just a UML/XMI library. The good news is that we think we have the API under control now. The bad news is, we have to completely redo the XMI stuff and parts of the UML stuff to work with it. It's unlikely to be in the preview release.

What's different between ZPatterns? and TransWarp?

ZPatterns is only useful in the Zope environment, TransWarp is a generally useful Python tool. ZPatterns includes a custom aspect language, "SkinScript?" for implementing data storage aspects, while TransWarp uses Python FeatureDef objects so you can effectively create your own "mini-languages" for any kind of aspect. ZPatterns provides you with a few fixed Service types (Specialist, Rack, etc.) and a couple kinds of Features (attributes, propertysheets). TransWarp lets you make up any kind of ServicesElementsAndFeatures, and ultimately will even assemble Services and Elements from Features according to your supplied UML model(s).

Will TransWarp replace ZPatterns under future versions of Zope?

That's the idea, although there may still be some sort of package called "ZPatterns?" that defines a few standard Services and Features similar to those in the current ZPatterns. Also, it's possible that various capabilities which are now part of ZPatterns will move into the Zope core, such as those provided by the PlugIns package.

How hard will it be to port my ZPatterns applications to TransWarp??

Our hope for ZPatterns?-to-TransWarp migrations is that the benefits of recreating your app as a UML+Python subsystem should outweigh the pains of copying or exporting code from your ZODB-based apps. Our advice to you is to create a UML model as a first step before creating a ZPatterns application, and to keep it as current as practical. Then, as the TransWarp UML tools become available, you can use them to swiftly regenerate your application's structure.

Advanced or Technical Questions

Do I need ExtensionClasses or any C extension modules to use TransWarp?

Not to do AOP. The TW.Aspects module uses only pure Python, and optionally uses Aaron Watters' "kjbuckets" extension module. There is a Python-only version of kjbuckets included with Gadfly, though, so if for some reason you can't use C extensions, you can use that.

The rest of TransWarp?, however, uses ExtensionClasses heavily, especially to implement acquisition relationships between ServicesElementsAndFeatures.

So if it's 100% pure standard Python, can I use the AOP part with Jython or JPython?

Probably not, since we mess with Python innards that may not apply under Java. For example, we put things into module dictionaries and create classes on the fly (without using exec). But you're welcome to try it and let us know what you find out.

If TransWarp uses nested classes, how can you pickle the instances, as is needed for ZODB?

Aha, someone's paying attention. Luckily, so were we. When you weave an aspect into a class, you can specify a module name into which the nested classes will be injected. The nested classes are given "nested names", so that they don't conflict with top-level names. For example:

    class MyAspect(Aspect):

        class Nested:
            pass

    MyClass = MyAspect(name='MyClass', module=__name__)

The above code, when run, will create two classes: one whose __name__ is "MyClass?", and the other which will be "MyClass.Nested". Both will be placed in the module specified by the module= parameter. If you omit the module= parameter, the nested classes will not be accessible for pickling. If you omit the name= parameter, the created classes will be named "MyAspect?" and "MyAspect.Nested". (But they will only be placed into the module dictionary if you supply the module= parameter.)

If you find any of this confusing, here are two simple rules to follow:

1. If you want the class __name__ attributes to start with something in particular, pass it in as name= at WeavingTime?.
2. If you want to be able to pickle instances of any classes contained in an aspect, pass in module=__name__ at WeavingTime?, which should be done while your module is being imported. This will ensure that the Python pickling system will be able to find your woven, nested classes when it's unpickling their instances.

How is TransWarp?/AOP different from just using Python metaclasses?

Actually, TransWarp implements AOP using Python metaclasses. But the key difference over "vanilla" metaclass usage is that TransWarp uses metaclasses only as an intermediate step to generating "real" classes. If you use metaclasses alone, you end up with a combination/integration problem. Think of it this way: theoretically you can do anything TransWarp does with __getattr__ hooks, or the metaclass equivalents thereof. But you can't easily combine __getattr__ hooks or metaclasses written by different authors, for different purposes, without editing and copying code. With AOP, you at least have a chance. Second, once you've placed your metaclass or hook at a particular part of the inheritance tree, any redefinition requires re-implementation of all the classes in the inheritance subtree. TransWarp lets you "inject" behavior into an ancestor class and propagate it to its subclasses. (Actually, it creates a whole new class hierarchy for you, but the point is that you don't have to do it.)