technology from back to front

One thing and one thing only

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 package. 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:

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.

by
Frank Shearar
on
30/06/13
 
 


× 6 = twenty four

2000-14 LShift Ltd, 1st Floor, Hoxton Point, 6 Rufus Street, London, N1 6PE, UK+44 (0)20 7729 7060   Contact us