Refactoring in Tunes

Brian T. Rice water@tunes.org
Sat, 08 Jan 2000 18:53:29 -0800


Sorry, Bill, I forgot to send the post to the list.

>Date: Sat, 08 Jan 2000 18:16:43 -0800
>To: btanksley@hifn.com
>From: "Brian T. Rice" <water@tunes.org>
>Subject: RE: Refactoring in Tunes
>In-Reply-To: <4B01F81CE2B1D2119A0D006097BA9D1E2B8EE9@mailman.hifn.com>
>
>At 04:59 PM 1/8/00 -0800, btanksley@hifn.com wrote:
>>> From: Laurent Martelli [mailto:martelli@iie.cnam.fr]
>>> Subject: Re: Refactoring in Tunes
>>> I can't what makes C more difficult to refactor than smalltalk. I
>>
>>I didn't mention C at all here.
>>
>>However, let's take a look at it.  C has slightly stronger typechecking than
>>Smalltalk, so the C compiler will warn you of a few errors; however, C's
>>typechecking is weak enough that if you try to take advantage of it you'll
>>wind up letting a lot of errors slip by you.  Advantage: neither one.
>>
>>Smalltalk has more possible refactorings: it's easy to make a "parameter
>>object" im Smalltalk, and it's hard in C.  It's even harder in C to do
>>refactorings which "split" a function which has internal state, but
>>Smalltalk (of course) has no trouble at all.  Strong advantage to Smalltalk.
>>
>>Smalltalk wins versus C, all in all, because as an OO language it has many
>>more possible refactorings.  Smalltalk looks a lot worse than Java for
>>refactoring, but because Smalltalk is interactive, it's possible to get your
>>unit tests out of the way a LOT quicker, and this speed encourages frequent
>>refactoring, which makes the final design likely to be a LOT nicer.  In
>>addition, Smalltalk has tools for refactoring which are only beginning to be
>>developed for Java.
>
>As a side note (not for Tunes), there does exist an implementation of
interfaces for smalltalks. Wouldn't this allow some of the refactoring
possibilities that Java enjoys? Or am I missing the point?
>
>Also, thanks for spending the time to correct fellows like Laurent who
speak without having learned anything on the subject.
>
>	Brian
>