Bijan,

The concern that inspired me to rescind my earlier implementation is 
actually well illustrated by the change-set you just posted, in 
which, in order to record the simple reclassification of a single 
method, your fileout ended up containing a huge "reclassification" 
specification for all of the 350-some-odd messages of class Object.

(This happened because you ended up doing a reorganization of Object 
in order to get your one change recorded.  But this is also what 
*would* happen if my original implementation were restored -- any 
individual reclassification would result in the filing out of the 
complete organization of the class.)

Besides the inelegance and wastefulness of this, there is actually 
some potential for loss here.  Even though a user's only gesture had 
been a simple reclassification of a single method, the fileout 
contains proactive assertions about the classifications of all the 
methods in the class.  This raises the potential for the fileout to 
clobber classifications made by other fileouts, such as by updates 
issued after the fileout was written but before it was published. 
And our conflict-catching tools could not -- at present anyway -- 
offer any assistance here.  And the unintended reassertions of 
categorizations  can clobber any competing organization work done in 
anyone else's image into which it gets filed in.  Even to the extent 
of replacing perfectly good categorizations with reversions to "as 
yet unclassified" -- believe me, I've seen it happen.

What we *really* need here is a way for a change-set to keep track of 
an explicit reclassification of a single method.

If we had this, then, using your recent fileout as an example, we 
would see something similar to the following at the end of the 
fileout, instead of the huge and largely extraneous reclassification 
spec for the entire class:

   Object organization noteClassification: #contentsChanged under: 'contents'.!

We wouldn't issue #classify:under: in the fileout, because we want 
the same reclassification note to be recorded in the current 
change-set of an image into which the fileout is subsequently filed 
in.

So instead, I'm hypothesizing adding a new #noteClassification:under: 
method to ClassOrganizer, whose implementation would be both to 
reclassify the method in question (by calling #classify:under:) and 
to make a note of that reclassification in the current change-set.

When a person proactively does a reorganization of a class's 
categories, he is consciously submitting a complete new take on this 
matter.  This doesn't mean that there is no potential for just the 
sort of harm I mention above, but at least the person was clearly 
aware of submitting the complete reorganization, whereas in the case 
of an individual method-reclassify, the person would be justified in 
assuming that the only thing his gesture would affect was the 
classification of that one method.

Perhaps, inspired by this little exchange, someone will feel moved to 
"do the right thing" here, i.e. modify the change-recording code so 
that individual method-reclassifications can be recorded 
individually, and modify the change-set fileout logic so that the 
correct and concise reclassification requests are issued.

A related improvement would be for the renaming of a message category 
also to be representable in a ClassChangeRecord, so that we could end 
up with concise items in a fileout of the form:

   Foo organization renameCategory: 'bindimg' newName: 'binding'!


Cheers,

  -- Scott


PS:  As a practical matter, note that what we often do to get the 
reclassification of a single method recorded in a change-set in such 
a manner that it does not generate the undesirable full 
reorganization is simply to resubmit the method into the desired new 
category, even though we are not actually changing the code.  That 
way, the method goes out on the fileout with the new category 
specified in the #methodsFor: header.


  At 8:39 PM -0400 10/14/01, Bijan Parsia wrote:
>This came out while preparing a changeset for submission (to be sent in a
>minute). I wanted to change the categeory of a method, and I saw the handy
>dandy "change category..." menu item in the messages menu list. Cool! So I
>used it. But duh and bummer, nothing showed up in the changeset! I
>wouldn't have noticed it if it hadn't been a very small changeset that I
>was preparing for submission. Bad bad!
>
>A bunch of investigation later (including close comparison of reorganize
>vs. change category...) leads me to this in CodeHolder>>changeCategory:
>
>	"Smalltalk changes reorganizeClass: aClass."
>	"Decided on further review that the above,
>	when present, could cause more unexpected harm than good"
>
>But but but! All ChangeSet>>reorganizeClass: *does* is:
>
>	self atClass: class add: #reorganize
>
>And, as far as I can tell, that's the *only* place it happens.
>
>Note that Browser>>changeMessageCategories: uses this line, and changes
>made by it show up.
>
>I'm a *big* believer in changes being recorded. I was wondering if Scott
>could explain what the putative harms are? If there are some, then reorg
>should reflect that too!
>
>Cheers,
>Bijan Parsia.