Refactoring in Tunes

[Laurent Martelli]

>>>>> "bill" == btanksley  <btanksley@hifn.com> writes:

  bill> Okay, I read through this, but I'm not sure I understand what
  bill> you're asking for.  "Refactoring" is generally used to
  bill> indicate the process of changing the way code put together in
  bill> order to produce a better fit to a better design.  In other
  bill> words, the programmer writes code, then realizes that a
  bill> different design would be better, and so he changes the code
  bill> to fit the new design.

  bill> Is that what you mean?

  bill> Refactoring in this sense cannot be helped by a runtime
  bill> system, but it can be helped by a language designed for it.
  bill> Forth is well-suited for refactoring because of its absence of
  bill> explicit variables; Java works well because of it moderately
  bill> strong compile-time typechecking (to help the programmer catch
  bill> typos written during the refactoring); and Smalltalk works
  bill> well because there are automated tools to performs some of the
  bill> most common refactorings.

I can't what makes C more difficult to refactor than smalltalk. I
think that refactoring does not only apply to OO languages. I see it
as finding patterns which are used more than once. 

If I have written somewhere 

        2+3*x+5*x^2

and somewhere else

        2+3*y+5*y^2

where x and y are of the same type (float for instance), I can create
a function :

float f(x:float) {
  return 2+3*x+5*x^2;

}

and replace the previous pieces of code by f(x) and f(y). 

When you're dealing with OOL, you introduce new base classes, but it's
the same mechanism.

-- 
Laurent Martelli
martelli@iie.cnam.fr