[squeak-dev] Modularity

David T. Lewis lewis at mail.msen.com
Tue May 3 22:29:48 UTC 2011


On Tue, May 03, 2011 at 04:51:48PM -0400, Chris Cunnington wrote:
> 
> 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.

Whoa! All that I did was some work to make MVC reloadable, largely
following the direction that Andreas put in place to enable organization
via projects and tool builders. I think that it is fair to say that
the approach works well and that further progress is waiting to be made,
hopefully to result in fully reloadable Morphic, SimpleMorphic, MVC,
and others :) But don't try to give me credit for making Morphic modular,
I most certainly have not done that ;)

If I were to summarize the approach to the extent that I understand it
so far, it amounts to carefully factoring things into their responsible
objects (e.g. MVCProject is responsible for a MVC-specific thing,
MorphicProject is responsible for an equivalent Morphic implementation,
and Project does as much as possible of the generic stuff). After you
get as much of that done as seems reasonable, tie up the remaining
loose ends as best you can. Use common sense to decide when the
factoring is starting to look over-engineered, so maybe a less the
perfect solution is good enough for now. An example of the latter
is Project>>dispatchTo:addPrefixAndSend:withArguments: which is an
awful hack to work around things that I did not understand well enough
to factor out properly. It's ugly, but it was good enough to get the
job done without waiting for a perfect solution.

So it's not rocket science. Just figure out where you want the
boundaries to be, factor things out as best you can, and tie up
the loose ends.

There will inevitably be compromises, so if you want to enforce
a package boundary you will probably end up with a few awkward
constructs to make it work. The corollary is that if modularity
is good, it does not necessarily mean that more modularity is
better.

Dave




More information about the Squeak-dev mailing list