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
. Alarm bells should be going off: things called “miscellaneous” or “utility” mean “things we couldn’t find a better place”. In particular,
has a class variable called
. This variable contains a
, from the
is one of the user interface frameworks that ships in the base Squeak image. As it happens, I’m trying to make
unloadable. That means that as few packages as possible should depend on
as possible. But Utilities contains other “miscellaneous” things, like the current author. As a result, many packages depend transitively on
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,
, 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.
now longer has a direct reference to a
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:
Utilities class >> emptyScrapsBook
ScrapBook default emptyScrapBook
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.