Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!tektronix!sequent!mntgfx!ssridhar
From: ssridhar@mentor.com (S. Sridhar @ APD x3561)
Newsgroups: comp.lang.smalltalk
Subject: Re: Organization of st80 programs
Message-ID: <1989Sep8.011452.22356@mentor.com>
Date: 8 Sep 89 01:14:52 GMT
References: <57318@aerospace.AERO.ORG>
Reply-To: ssridhar@mntgfx.UUCP (S. Sridhar @ APD x3561)
Organization: /etc/organization
Lines: 52

In article <57318@aerospace.AERO.ORG> abbott@itro3.aero.org (Russell J. Abbott) writes:
>
>Most programming languages do not implement complete environments.  An
>advantage of this "failing" is that the programmer is then free to use
>Unix's capabilities and build arbitrary directory and file structures
>that reflect the system's structure.  In st80, one's only (apparent)
>organizational options seem to be (a) the class hierarchy and (b) the
>class categories.  For a complex system these organizational options
>appear far too limited.  How do real st80 programmers organize their
>code?                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>^^^^^

At Tektronix, Ward Cunningham & Dale Henrichs invented a technique called Change
Sorting. The basic philosophy is that the fundamental unit of distribution among
Smalltalk programmers is the set of changes made to some baseline image.
Therefore if Joe is working on two projects (perhaps simultaeneously), somehow
he would need to partition the changes made to the baseline image into two
distinct "change sets". The default Smalltalk-80 virtual image contains only a
single change set. The Change Sorting idea is to have multiple NAMED change
sets. Thus your programming activity consists of two phases: writing code and
then sorting (organizing)  the classes or methods that you have changed into one
or more named change sets.

   Managing named change sets is done by a browser-like tool called the change
sorter. I'm not going to describe the anatomy of this tool other than to say
this:  all the changes that you have made to the image in the "current session"
appears in one pane. The changes can be any one of the following: method change,
a class definition change, a class comment change, protocol reorganization,
class removal. method removal etc. You can then selectively MOVE or copy each of
these changes to one or more named change sets. Of course the change sorter
allows you to create, rename and delete change sets. The change sorter user
interface also allows an easy way of moving/copying changes from one change set
to another. This is done because a particular method may actually belong to more
than one change set. Furthermore you could file out the named change set and
your friend can then file it into his image. 

   Another related tool that is really helpful is some kind of a versioning
tool. This enables you to fearlessly modify a method (or a class). A typical
scenario is this: your friend Harry comes to your desk with a problem. You,
being a nice guy immediately set about doing some exploratory programming with
Harry and after a while you've solved the problem. Except one thing. You need to
distribute the changes to Harry so that he can install them into his image. So
you go to the change sorter. Recall that the changes you made may be adding a
new method to an existing class, changing an existing method, adding or changing
class, removing a method and so on.  Move the changes you and Harry made
to a new named change set, file the named change set out and ship it to Harry. 
With the versioning tool, then you can retrieve the previous versions of
methods/classes that were modified.

   As you have pointed out in your posting, organizing projects into just
classes or class categories is restrictive beyond a point. A named change set
is one way of saying "This is my program that does this specific thing."