The SOB was supposed to meet today, but a number of things seemed to 
make that difficult. This is relevant, because I was going to harvest 
our discussion on modularity and present it in my first post on the topic.

I'll present that material after we've had that meeting. It revolves 
around the implementation of this plan:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html

There are, it seems to me, two sides to the modularity question. The 
first is the range of topics addressed in that post. They concern 
managing a modular Squeak. It's mainly about tools and infrastructure. I 
guess we could lump that stuff into a box called "external matters."

I'm going to take a run at describing the other half of a plan for 
modularity. I'll term these "internal matters", matters that exist 
inside the image.

A while back David T. Lewis made an advance by making Morphic modular. 
Recent days have led me to believe that the problem he solved concerned 
"circular dependencies". As far as I understand it, this is the big 
problem with making Squeak modular.

I have a package I'm working on called GreenNeon. It has dependencies. 
When you load it, it expects certain classes from some packages will be 
there. We're all familiar with this when we load things with Monticello, 
which has a serialized object graph that travels with each file. MC 
compares what it sees in an image with what's in the serialized object 
graph and might say, "You're missing a dependency. You can't load this."

If Squeak were a giant tree diagram of classes, then GreenNeon would be 
a leaf node at the bottom of the tree. It depends on many things (which 
you can see in the DependencyBrowser i.e. DependencyBrowser open), but 
nothing depends on it. As such it's ideally modular. If you remove 
GreenNeon, Squeak is not going to collapse.

Let's say we move up the tree (I posit that Kernel is at the top of the 
tree) then the greater the interdependence of the packages and the 
greater the likelihood of circular dependencies. I guess to make Squeak 
modular all these circular dependencies need to be identified and a 
layer of indirection placed between all of them depending on the 
packages they are in. I imagine the package Collections, owing to its 
essentialness, has a lot of circular dependencies.

I'm not sure how a person sees a circular dependency. I don't see it in 
the DependencyBrowser. But I have a feeling that the book Refactoring: 
Improving the Design Of Existing Code is all about this. As the 
RefactoringBrowser is based on the precepts of that book, I bet you can 
see circular dependencies and do just this kind of surgery.

That's the extent to which I understand the problem so far. If anybody 
could shed light on this topic (and my misconceptions), that'd be great. 
It's good that some people understand these things very well. I believe 
it would worthwhile, though, if everybody in the community has a better 
grasp of the criteria of the problem as we move forward.

Chris