Dan Ingalls wrote:
I agree it is essential to be able to do this kind of refactoring of the module structure again and again. When I did the Environments work, I took some time to refactor the systemOrganization somewhat, as this is what I used as the basis for the module structure produced by reorganizeEverything.
It ain't a tool, but the essence of a tool can be found in
Smalltalk tallyIndirectRefs
However, before I leave town, I will try to have this stuff working again to the point that the image can be refactored and stay running. Then while I'm away, people can have fun messing around with the structures and the factoring. It should be instructive whether or not we end up using any of it.
- Dan
--
Dan, this is already working (still) in 3.1a. I've been using it when I looked at the Environments stuff.
There is one fix that you would want however after converting to Environments, make this change to avoid an image crash when an exception is raised:
Dictionary>>includesKey: key "Answer whether the receiver has a key equal to the argument, key."
^(self at: key ifAbsent: [nil]) notNil
I posted this as a fix.
Do exploreIt on "Smalltalk tallyIndirectRefs" for best results.
The third returned dictionary is the most interesting one imo. The others mostly say that 700 classes would be happier if they were placed in Smalltalk (doh).
It lists non-modular refs by occurrence count. This shows that most go to things like the basic collections, note that Tools, Morphic et al are references to other namespaces. Hopefully most Color refs are from the graphics packages, which should be ok, and so on. But there is a lot of work cut out for us.
Henrik
269->#Array 254->#Color 168->#OrderedCollection 135->#String 111->#Tools 110->#Smalltalk 106->#Form 95->#Morphic 95->#Time 95->#Dictionary 88->#WriteStream 82->#Display 77->#Character 70->#Sensor 64->#Preferences 57->#Cursor 52->#Transcript 52->#FileDirectory 52->#FileStream 47->#ReadStream
etc.