I think you might mean the Module refactorings, that is, moving classes
between modules and creating new modules. About those, I agree, but
that's not the problem I mean.

Actual code refactorings (the classic - making a list of hard coded
references into a dynamic registry, like Henrik and Stef did for the
file list) are required to break the bad dependencies.

The problem is that when you refactor, you often touch a lot of code.

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

David Farber <dfarber at numenor.com> wrote:
> 
> Daniel -- One possibility would be to record refactorings as /commands/ rather than code changes. So when a module (or any change set for that matter) gets imported the refactorings are run against the new system. I think that would go a long way towards removing the brittleness of certain changes.
> 
> Of course, live refactorings would have their own issues. Something like a "Refactoring Preface" to hold the refactorings might be in order. Then you could opt not to run the refactorings.
> 
> david
> 
> At 07:55 PM 5/22/02 +0300, you wrote:
> >* Modularization requires refactorings. These are notoriously brittle if
> >not inserted into the image fast. What do we do? prioritize the
> >integration of modularizations over fixes/functionality? 
> >
> >Daniel
> >
> >
> --
> David Farber
> dfarber at numenor.com