[BUG] Problem with renaming classes

Boris Gaertner Boris.Gaertner at gmx.net
Wed Oct 9 16:28:33 UTC 2002


Ken Causey <ken at ineffable.com> wrote:

> I'm using 3.2-4956 and I think I've found a problem with renaming a
> class.  I created a class named CutterShape.  Later on in the design
> process I renamed this as SegmentedCutterShape, and then created a new
> class CutterShape which became the super class of SegmentedCutterShape.
> In my original image the change sorter shows for SegmentedCutterShape:
>
> New class comment.
> Class definition was added.
> Class name was changed.
>
> And for CutterShape:
>
> Class definition was added.
>
> But a filed out changeset only shows:
>
> Object subclass: #CutterShape
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: ''
> category: 'ineffable-puzzled'!
>
> ...snip...
>
> Smalltalk renameClassNamed: #CutterShape as: #SegmentedCutterShape!
> CutterShape subclass: #SegmentedCutterShape
> instanceVariableNames: 'vertices '
> classVariableNames: ''
> poolDictionaries: ''
> category: 'ineffable-puzzled'!
>
> But then no further
>
Class>>subclass:instanceVariableNames:classVariableNames:poolDictionaries:ca
tegory:
> references for CutterShape.
>
> So the result if I file this into an image is a SegmentedCutterShape
> subclassing ProtoObject.
>
> Needless to say, this is annoying.
>
This is really an interesting scenario. Change sets try to record
your changes to reproduce them in a differnt image.  This does
not cover all possible scenarios.

To avoid the problem, you can choose one of two solutions:

*first workaround*
In the change sorter, the menu of the top left view (The list of
the change set names) has an item "trim history" (to see it,
you have to select "more ..." first.)
This drops the changes history (regrettably the entire history).
A change set withou history will can be filed in without the
problem that you found.

*second workaround*
Do not rename the class, but copy it and give the copy the name
you want to see.
Make the old class the superclass of the copied class and
remove all methods that should be defined in the subclass
only.

This gives a change set that can be loaded without problems.

The second workaround has the advantage that you do not loose
important deletions that are recorded in the change history.

For the moment I cannot propose changes in the code of the
change sorter and its coorperating classes, but I will try to
analyze what we have. The problem with changes in tools is that
you can very easily introduce new unwanted  effects.

Greetings, Boris





More information about the Squeak-dev mailing list