[squeak-dev] Modularity

Casey Ransberger casey.obrien.r at gmail.com
Wed May 4 00:47:37 UTC 2011


Resolving circular dependencies is *necessary,* so if you've been putting work into that: thank you. 

I think we're conflating a few issues under the umbrella of "modularity." Has anyone here ever read "the Modularity Complex?" Fun read BTW, if you don't mind a lot of parens. 

* Circular dependencies
---> evil, terminate on sight where possible. Obviously we can't get rid of all of them. 

* Community supported packages
---> relevant but perpendicular to modularity itself

* Namespaces
---> a requirement for what I would call "true modularity" wherein one package can only depend on any class in another package by naming the package *explicitly* a la:

(Kernel at: Object) new. "Insert a better EDSL for name spaces here."

*or* explicitly state the package we're extending in our class defs, a la:

Object subclass: #Foo
instanceVariableNames: 'bar baz'
inPackage: 'Foo-Core'
includePackages: 'Bar-Core Baz-Core'
...  

In which case our class is loaded into Foo-Core, and has access to all of the objects that are global only to Bar-Core and Baz-Core. 

If you do it right, you can also get the equivalent of mixin inheritance almost for free while you're at it. 

Sorry to repeat myself yet again, but I must *strongly* urge the community to *please* pull down a Pharo image, load up the Environments package, and give it a test drive. 

There's a great demo of it in a video but I'm having trouble finding it. I have to say that I thought the "language" used to express the trappings of namespace in Environments were rather beautiful. 

In late bound languages reifying packages as namespaces makes reasoning about the dependency graph a lot easier because you have smaller buckets to look in, and hunting down a dependency between buckets is easy, because the buckets are named (read: searchable.)

I suppose I don't really need to say that it can be hard to know concretely that X depends upon Y when in many cases you don't know the "type" of Y until runtime. In many cases all we can concretely say is "X probably depends on Y, or at least something that responds to the same protocol as Y."

Knowing that X and Y are in the same namespace reduces the amount of hunting you have to do in order to suss out the dependency relationship, and whenever a dependency crosses a module boundary, it's explicit, so you know where to go looking right away.

I realize that integrating something like this is a lot of work, especially around tool support. I also recognize that we don't need namespaces in order to refactor and resolve cyclic dependencies that shouldn't be there. I will even admit that perhaps namespaces shouldn't be the highest priority on the list, even though I'm all about it!

But I want to do my part to make sure we're looking at the *whole* issue. Does that make sense? Sorry to be a brat. 

On May 3, 2011, at 1:51 PM, Chris Cunnington <smalltalktelevision at gmail.com> 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 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
> 



More information about the Squeak-dev mailing list