[TransWarp] FYI: Coming refactorings, Builder interface changes

[Phillip J. Eby]

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 
builders

* 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.