abbott@aerospace.aero.org (Russell J. Abbott) (09/06/89)
I have just started to write a serious(?) program using st80 and have noticed realized that I don't know what capabilities are available for organizing my code. In this and the following message, I sketch my questions and solicit any advice. 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? -- -- Russ abbott@itro3.aero.org
ssridhar@mentor.com (S. Sridhar @ APD x3561) (09/08/89)
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."
johnson@p.cs.uiuc.edu (09/11/89)
As a matter of fact, class categories are the main way to organize classes. There are a number of design techniques that are commonly used, such as building a subsystem whose interface to the outside world consists of only one or two classes. The ST-80 compiler is a good example of this. When possible, all the classes in the subsystem are put in one category. Unfortunately, there is no way to hide all but the interface classes. However, it is pretty easy to implement "modules"; one of my students had a class project in which classes could be stored in pools other than Smalltalk. Smalltalk programmers seem to get along reasonably well with the tools in the system, but large applications could definitely use tools that increased modularity. Ralph Johnson