Refactoring in Tunes

[Laurent Martelli]

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

  >> From: Laurent Martelli [mailto:martelli@iie.cnam.fr] Subject: Re:
  >> Refactoring in Tunes

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

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

  bill> I didn't mention C at all here.

I I don't think that a language is more refactorable than an other, so
I just took C as an example.

  bill> However, let's take a look at it.  C has slightly stronger
  bill> typechecking than Smalltalk, so the C compiler will warn you
  bill> of a few errors; however, C's typechecking is weak enough that
  bill> if you try to take advantage of it you'll wind up letting a
  bill> lot of errors slip by you.  Advantage: neither one.

What has refactoring to do with typechecking ?

  bill> Smalltalk has more possible refactorings: it's easy to make a
  bill> "parameter object" im Smalltalk, and it's hard in C.  It's
  bill> even harder in C to do refactorings which "split" a function
  bill> which has internal state, but Smalltalk (of course) has no
  bill> trouble at all.  Strong advantage to Smalltalk.

I don't see what you're talking about. Can you give an example ?

  bill> Smalltalk wins versus C, all in all, because as an OO language
  bill> it has many more possible refactorings.

What makes you think so ?

  bill> Smalltalk looks a lot worse than Java for refactoring, but
  bill> because Smalltalk is interactive, it's possible to get your
  bill> unit tests out of the way a LOT quicker, and this speed
  bill> encourages frequent refactoring, which makes the final design
  bill> likely to be a LOT nicer.  In addition, Smalltalk has tools
  bill> for refactoring which are only beginning to be developed for
  bill> Java.

  >> think that refactoring does not only apply to OO languages. I see
  >> it as finding patterns which are used more than once.
  bill> [snipped: example of finding redundant patterns, making them
  bill> into a function, and calling the function from both places]

  bill> No, that's function factoring, not Refactoring.  My
  bill> "Refactoring" book calls that "Extract Method".  Refactoring
  bill> also includes the inverse of that -- "Inline Method".  A good
  bill> coder should know how to do both refactorings; sometimes you
  bill> need to inline a method in order to get special behavior

Are you saying that there are things that you can only do by inlining ? 

  bill> (or because you made a poor choice of factoring earlier and
  bill> now you have to redivide your functions' functionality).

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

  bill> The full art of refactoring is about being able to change the
  bill> design of a program, not simply make it take up less space.
  bill> You accomplish that change in two steps: first, you apply
  bill> source changes which preserve the old behavior but provide a
  bill> more suitable class or function layout (these are what Fowler
  bill> calls "refactorings"); and second, you change the arrangement
  bill> of these new classes to provide your new behavior.

Thanks for the clarification on the meaning of refactoring. But I
still don't see why refactoring could only be applied to OO. Excepted
that you use `class' in your definition. If you only take the first
part of the defitinition (``The full art of refactoring is about being
able to change the design of a program''), it can be applied to any
language. 

-- 
Laurent Martelli
martelli@iie.cnam.fr