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

Hi Chris, virtually everything in that post has been fulfilled by the
advancements made to SqueakMap.  We have Community-Supported Packages,
see "Connectors" as a working example of this,

  http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-February/157475.html

and anyone can visibly contribute to Squeak by simply adding entries;
with one "4.2" release and one "head" release per entry on SqueakMap.

"4.2" releases will forever be compatible with 4.2.  "head" are
forever the latest code, and update that "module" in the same way our
trunk process updates our image.

A lot of thought went into this approach, including making sure to
incorporate everything from Andreas' post you referenced.

BTW, I thought that since GreenNeon is a rewrite of the SqueakMap
server..?  If so, that's GREAT because that's the part of SM that most
needs to be replaced.

 - Chris




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