Refactoring in Tunes

[Brian T. Rice]

Hello, Tunesers all.

I've been working over my designs in my head, on paper, and in Squeak, as
well as comparing notes with Tril and his ideas.  Of course, everything
that Fare has said at one time or another has made an impact on me. I'd
like to thank them both and all of you who have tolerated my rants.

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 admitted that the
term really arose as an issue becuase current oo language styles make
refactoring less than trivial, even tunes has not addressed this the way I
believe it should. Let me explain why.

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:

1) How fine a grain is reasonable achievable?  More to the point, how fine
a grain would someone potentially want?

-In modern OO languages (Beta, Scheme, Self), differentiation of
functionality is the same as subclassing, and refactoring introduces new
classes between old ones in the chain of inheritance.

2) What are the best methods for differentiating objects and their
functionality? Or, more relevant to tunes, how do we create these methods
and how can this system for creation be made the most general?

-This in modern languages, seems relatively ignored, but its answer affects
the ability to answer the former question.

Well, I have various ideas on how to answer this in the ways that Tunes
should, but of course I'm looking for your thoughts here. I consider
particularly important the possible aspect of *automating* refactoring.
This can be quickly formalized in terms of the formal logical theory of
classes, where differentiation is via predication of unique properties (in
fact, predication defines classes themselves in logic). Predication relates
to my notion of specifying graphs axiomatically and also fits loosely with
Tril's type system ideas. One prickly point about differentiating via
predication is that object differentiation becomes fairly complex (one has
to resort (at the least) to full lattice theory).

Well, any ideas and questions you have would be welcome. Particularly
welcome would be quoting HLL requirements and using those as a basis for
discussion, since we could apply the results back to the page itself (yes,
and we really *should* do this, imo).

Thanks
	Brian