On Tue, 3 May 2011, Chris Cunnington wrote:

> 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

Not all circular dependencies can be/have to be removed. For example, 
Kernel uses instances of Array which is in the Collections package. But 
Array is a subclass of Object which is in Kernel. We'll probably split 
both Kernel and Collections to make it more modular, but we'll probably 
never resolve this circular dependency, because we wouldn't gain anything 
from it.

The ideal dependency graph is not a tree, but a DAG [1]. Therefore your 
package is not a leaf, but a node with no outgoing edges (or incoming 
depending on the meaning of edge directions).

> 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.

The dependency browser doesn't show it, but the information can be 
extracted from it. Finding a circular dependency is as easy as finding a 
circle in the dependency graph (which is pretty easy to do).
There are existing tools for detecting circular dependencies for example: 
http://www.squeaksource.com/dsm.html

Note that the dependency browser doesn't show all dependencies, because 
it doesn't know the classes of the possible receivers for all methods. 
There are also ways to generate a message and send it on the fly, which is 
almost impossible to detect with tools.


Levente

[1] http://en.wikipedia.org/wiki/Directed_acyclic_graph

>
> 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
>
>