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.