danielv at netvision.net.il wrote:

> * As I discovered, it's not trivial to package modularizing code in a
> manner that's understandable/appliable by clean images. If there are no
> guideline, we'll get every variation possible.
> 

Well that is exactly why these should be done as subclasses of
ModuleRefactorer. Look at the existing ones. This is then put in a change
set along with any methods that are changed/moved/removed etc.

> When someone else fixes a bug or adds a feature in the old (for example,
> one more class in that list of references), there's a good chance
> they'll break your code. So if refactorings don't get fed back into the
> image, they die a quick and nasty death. That's what I mean.
> 
> If we want refactorings to work, they need to get in before the code
> changes. Either quickly, or we can say that people now don't add
> anything into (e.g) Celeste, until the refactored code apears in the
> updates, so further work will take the refactorings into account.
> 
> Daniel

SqC and Dan have been pretty good about this so I don't think it will be a
problem if the code is well done and of good quality. When it is approved
then I think it will be adopted in the next set of updates or so. That has
been the case in the past.

H