On Mon, 27 Jun 2005 18:26:21 +0200, "Bert Freudenberg" bert@impara.de said:
Am 27.06.2005 um 18:18 schrieb Alexandre Bergel:
right. I guess you are referring to the Reorganize.3.8-6662.cs. There are just some categorizations. Bert, I did not deeply checked but I feel that actually it does not assign new category to classes/ methods. For instance, the first line of the changeset is
SystemOrganization changeFromString: '(''Kernel-Chronology'' ChronologyConstants Date DateAndTime Duration Month Schedule Stopwatch Time TimeStamp Timespan TimeZone Week Year)
These classes are already included into the class category 'Kernel- Chronology'! Andreas worked on the system change notification, but I do not know what he did (I do not have time to dive into the iSqueak image). I suspect that it uses events triggered by the recategoryzation to create packages.
You need to inspect the change set more closely. It may well have redundant categorization of classes where nothing changed - this does not hurt anybody. But there are also many recategorizations of methods. I guess Andreas made the changeset by just filing out the categorization for everything in the system.
It is difficult to see exactly what changed in the recategorization, because the changeset includes the whole system as you say.
However, I did see that the Tests package was recategorized into KernelTests, CollectionTests, NetworkTests, etc., which is a significant change and seems like a good change.
Just curious, were any methods actually recategorized into mc-based extension method categories? (I didn't see any.) That would be a bigger change, as it would essentially move the method into a different package as an extension, even though it's still on the same class. A classic example would be moving String>>asUrl from the "converting" to the "*Network" method category, so that it ends up in the Network package. That's more of a real detangling/refactoring than a mere recategorization.
- Doug