VisualWorks 7.3 Smalltalk now includes a class hierarchy with Subsystem as its abstract root. I spent some time yesterday reading the code and comments of these classes. It took me a while to figure out what the word "subsystem" means in this context, and whether it refers to anything like what I understand a subsystem to be.

First off, a VW subsystem represents some aspect of the functionality of the total system; for each, a separate subclass of Subsystem. For example, there is a subclass for the CoreSystem, the BasicGraphicsSystem, and the WindowingSystem. There is also a subclass for UserApplication, which is intended to be for application defined subsystems. These subsystems can be loaded or not, and be "active" or not. Methods are provided for activating and deactivating subsystems. This includes prerequisite checking for other subsystems required to be active.

Initially, I wondered how these subsystems differed from packages, which also support prerequisite checking. But then I realized that package prerequisites are only concerned with what is loaded in the image. Subsystem prerequisites are about what is "active" and running in the system. What differentiates them is that a Subsystem class has to be instantiated as an object, and it is the subsystem object that is activated. A package is just a static packaging of a bunch of classes.

Clearly, the VW engineers are using these subsystems as a new way to structure and manage the functionality of their increasingly complex system -- nothing to argue with there. I have long been a believer in the aphorism "To build good systems, build good subsystems." Hopefully, the VW 7.3 support for subsystems is just a first step.

"Just a first step" because subsystems should (in my opinion) be viewed as entities at a level of abstraction beyond the "objects" one finds in a Smalltalk image. Rather than elaborate on this here, I'll just point to a paper I wrote on Subsystem Exception Handling in Smalltalk.