Refactoring in Tunes
Brian T. Rice
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
>From: "Brian T. Rice" <firstname.lastname@example.org>
>Subject: RE: Refactoring in Tunes
>At 04:59 PM 1/8/00 -0800, email@example.com wrote:
>>> From: Laurent Martelli [mailto:firstname.lastname@example.org]
>>> 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.