Package dependencies appear in many ways, some more surprising than others. Let’s see what we’ve recently dug up in the trenches.
Squeak has a class called
Utilities. Alarm bells should be going off: things called “miscellaneous” or “utility” mean “things we couldn’t find a better place”. In particular,
Utilities has a class variable called
ScrapsBook. This variable contains a
BookMorph, from the
Morphic is one of the user interface frameworks that ships in the base Squeak image. As it happens, I’m trying to make
Morphic unloadable. That means that as few packages as possible should depend on
Morphic as possible. But Utilities contains other “miscellaneous” things, like the current author. As a result, many packages depend transitively on
Morphic just because they happen to use some “general purpose” method.
The solution, as with so many other problems, is to separate concerns. I created a new class,
Scrapbook, and copied all the methods touching the class variables to this class, changing (modulo some unimportant details) references to the old class variable to references to self.
With this in place, isolating the scrapbook functionality in its own class, we can remove the class variable entirely.
Utilities now longer has a direct reference to a
Morphic class’s instance, and a host of packages have simpler dependencies. We can even preserve the existing API, in a deprecated form, so that existing code can migrate at leisure:
So next time you think of creating a “miscellaneous box”, for odds and ends that don’t seem to fit anywhere, try harder. Even if you end up with lots of very little boxes that do one thing and one thing only. Those small boxes will promote the modularity of your system.