Thank you for the education folks.  I knew there had to be a reason, but I
couldn't see it and now I see the light !!!

> From: Bob Arning [mailto:arning at charm.net]

> At this point, if the change set contains only the (final) 
> definition of ClassX with 'b c', then when the class 
> definition is compiled, all the methods referencing 'a' will 
> be recompiled and either generate an error or bytecodes that 
> don't work. Could be big trouble. Really big.

BTW, recompiling due to any class definition change should not cause these
kinds of problems.  This problem should be fixed regardless.  If I am
working in the image and change the class def, I should be able to go on and
fix the errors that were pointed out on the Transcript and not have big
trouble.  The change set semantics you provide are good in reducing the
error showing up on the Transcript, but the real problem still exists.

>It's not clear why this is a problem. Change sets are pretty simple:
> you file them out and you file them back in. >Exactly how many chunks
> of code that takes would not seem to be a big issue.

You are correct.  But I am anal retentive with what I used to think of as
clean change sets.  Plus, since I did not know this existed, I had a problem
in the past where I went to edit the change set and modified the first class
definition.  Only to find out that when the change set was filed in I did
not have the class definition I expected.  So now I have to make sure that I
modify both class defintion, or some appropriate combination of methods and
the other class def in order to modify the code in the file itself.  It took
me a while to figure out what was going on.