[TransWarp] FYI: Coming refactorings, Builder interface changes
Phillip J. Eby
pje at telecommunity.com
Sat Dec 29 17:41:28 EST 2001
I've just started reviewing the TW kernel for some possibly significant
refactoring of the build process. Some of the things I'd like to do include:
* getting rid of the 'parents' tuple chain parameter passing (since TW now
requires 2.1, weakrefs can be used instead)
* adjusting the build passes so that builders can be given a complete list
of specifications, rather than having to build incrementally upon previous
* adding callback hooks to parent builders so that other builders can
register to be called back when various build stages are reached.
The primary purpose of these refactorings is to make it possible to
implement AspectJ-like "pointcuts" and "advice" via Builder
objects. Currently such features would be extremely difficult to
implement. Secondarily, I hope to streamline the core code and fix up many
messy bits such as the peculiar precedence of postprocessors (try saying
*that* three times fast!) and the weirdness of 'replaceBuilder()'.
I think that all of these goals can be accomplished without affecting TW's
"external" API's much, if at all. However, because this is likely to
involve significant changes to various internal interfaces (primarily
IBuilder and IParentBuilder), your code may be affected if you have
developed any specialty Builder classes.
Of these changes, the change to remove the 'parents' tuple chain from the
API's is likely to be the most disruptive, unless for some reason you can't
use weak references. To date I have not had a need for any Builder object
to derive from a type that didn't support weak references, so I don't
expect this to be a problem. However, I will try to implement this in such
a way that you can use something other than weak references, if you must.
Anyhow... there is now a LAST_CHANCE_FOR_OLD_API tag in CVS, for the
convenience of those who like to follow the CVS version. When the API
upheaval dies down, I will post an explanation of the changes. I will also
do what I can to ensure that any of your existing incompatible code will
break loudly and quickly under the new API's, so that you'll be able to
easily find and make the needed changes.
Your questions and comments are welcome, as always.
More information about the PEAK