Refactoring in Tunes

[btanksley@hifn.com]

> From: Brian T. Rice [mailto:water@tunes.org]
> Subject: Refactoring in Tunes

> Hello, Tunesers all.

> To the point: I'd like to know what kind of policy Tunes has towards
> _refactoring_, which is an issue that current object-oriented 
> styles can
> address but have very limited expressivity to do so (Self being the
> untested possible exception to this rule). What I want to 
> know, before I
> scour through the mailing-list archives for the last few years, is how
> tunes intends to handle such an idea. Although it can be 

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

Is that what you mean?

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

Are we still on the same channel?

I'm pretty sure that we aren't, because with those definitions in mind, not
much of your post made sense to me.

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.

-Billy