Refactoring in Tunes

[Brian T. Rice]

At 02:53 PM 1/8/00 -0800, btanksley@hifn.com wrote:
>> From: Brian T. Rice [mailto:water@tunes.org]
>> Subject: Refactoring in Tunes
>
>> 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?

Yes and no. I'm throwing in the possibility of software-driven refactoring,
or at least providing tools that are better than the standard smalltalk
tools, and even better than those in the Self 4.0 environment.

More specifically, I'm talking about type systems, just as in smalltalk the
type system (via classes) is enhanced by the actions of refactoring. In
otherwords, to me its an issue of the construction of new types, which of
course would be goal-directed as smalltalkers understand it. In tunes, we'd
want the products of this goal-directed construction of useful types to be
shared (or at least sharable). However, as Fare puts it, a single global
type-hierarchy doesn't help Tunes, as it does the smalltalk community.

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

Well, I'd like to keep the Tunes goal in mind, which is to blur the
distinction between run-time system semantics and language, but for the
purposes of argument, yes, language is the issue.

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

Well, I'm considering the declarative specification of types, which is not
clear to the average object-oriented programmer, since they (you?) write
code which specifies protocols procedurally. I'd like to have protocols
pretty much declaratively specified, which leaves more type-inference and
optimization up to the run-time system (impossible in existing smalltalk
systems).

Let me try to clarify:

>> Refactoring (as best I can formalize) is the process of distinguishing
>> refinements of a particular idea at the finest possible grain. A few
>> questions immediately arise on reading this statement:

In smalltalk terms, this means that refactoring adds more classes to a
hierarchy, usually between existing classes in the inheritance chain. In
self, the ability to do this is simpler and more wide-ranging in scope. The
point is that to me, types exist to model ideas, and that refactoring
allows one's model to adapt to changing conditions or requirements; I
simply want to have handy declarative (not necessarily via first-order
logic) specifications for use in the system to be able to verify properties
of the source code (Tunes-style) even if I refactor my application set of
objects.

>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

Thanks for the thoughtful reply,
	Brian