Refactoring in Tunes

[Brian T. Rice]

At 09:47 PM 1/8/00 -0700, Jim Little wrote:
>btanksley@hifn.com wrote:
>> A professional discussion of refactoring (the definition I'm using) is
>> available at http://xprogramming.com, and is discussed at length in Martin
>> Fowler's "Refactoring: Improving the Design of Existing Code", ISBN
>> 0-201-48567-2.  I cannot recommend this book highly enough; it has changed
>> the way I code and design.
>
>I have to second this recommendation.  This refactoring book is quite
>simply the best "how to" manual for code I've ever seen.  Ostensibly
>about how to refactor, it's also the best set of examples of quality
>code I've seen.
>
>To help clear up some of the misconceptions about refactoring I've seen
>in Brian and Laurent's posts: refactoring is not about breaking code
>down into the smallest meaningful pieces, although that can be a useful
>application of refactoring.  Rather, as I believe Billy mentioned,
>refactoring is about changing the design of the code without changing
>the semantics of the code.  In practical terms, you refactor any time
>you need to modify a piece of code and the existing design doesn't allow
>you to do so cleanly.
>
>Martin Fowler's "Refactoring" book defines it thusly:
>
>"
>Refactoring is the process of changing a software system in such a way
>that it does not alter the external behavior of the code yet improves
>its internal structure.  It is a disciplined way to clean up code that
>minimizes the chances of introducing bugs.  In essence when you refactor
>you are improving the design of the code after it has been written.
>"
>
>Brian, you appear to be talking about something else, though I'm not
>sure what.  I'm not trying to nitpick you away from your point, but for
>the sake of clarity I thought it was worth discussing the definition
>further.
>
>Jim

This definition doesn't apply to tunes, it applies to an ad-hoc notion of
refactoring which arose from the problems that current object-oriented
languages have with matching code to the application domain.

I disagree here about what we're calling a program and what it's
application is. I don't intend on having refactoring change the over-all
effect of the set of code on its intended domain, I simply mean what the
book does: that refactoring allows a cleaner, more effective way of having
the code deal with the domain. A lot of refactoring methods change the type
system. You fellows have the approach in mind that *will not work* for
Tunes, because your classes have mutable states. Your classes change in
time, and are application-driven, whereas tunes-style types will be
*chosen* from a network of meaningful types and representations. Within
tunes, you specify a more appropriate type rather than change the behavior
of the existing type, which allows for better verifiability of code.

In smalltalk, you throw away code that doesn't interface well with other
code. I'm saying that with a properly designed object-oriented language,
this should be a non-issue. I want a type system declaratively specified,
so that proper behavior is lazy, proper to the model of the domain, and
automatically-generated (easily meta-programmed). Smalltalk's
object-oriented approach is ad-hoc and procedural in nature, so the whole
approach doesn't apply to tunes.

My idea here of a type system is one specified in the manner of predicate
logic (though not with standard predicate logic only). Subclassing in tunes
would not be "overridding methods" and "adding variables" but specifying a
type that obeys more specifications.

	Brian