Previous Table of Contents Next


3.5.2. Composition Architectures

Another invention of Smalltalk-80 was derived from earlier work done in Smalltalk-76. In Smalltalk-76, the programming tools were done with what Ingalls called “pluggable interfaces.” The idea was to create a framework with which an application was formed by composition of components. A class acting as a kind of scaffold for the framework demands that a precise set of messages be implemented in order to participate in the composition. The basic composition idea is simple and much like that used by the earlier Smalltalk galley editor. But pluggable interfaces were made harder to understand by allowing the programmer to declare alternative message names to fulfill the required component behaviors. Declaration was done at the time a component instance was created, written as literal symbols and therefore not easy to cross reference with the typical Smalltalk browsers. This design is in contrast to the subclassing approach, whereby the scaffolding class provides default behavior for an application. Subclasses then reimplement inherited messages to create alternative application behavior. And of course, the cross-reference tools can find and display these subclass refinements.

The work on pluggable interfaces represents one of several efforts in the Smalltalk research to create an architectural style for how objects with particular roles should relate to one another. Probably the most widely known delete style is MVC (which stands for “model, view, controller”), having gained most recent fame as one of the few design patterns with any real use history (Krasner & Pope, 1988).12 The MVC idea came from several sources; it was recommended by Trygve Reenskaug for his application work in Smalltalk-76 (Reenskaug, 1981) and used by the database community as a style for handling multiple viewer interest in a shared database. MVC was implemented in Smalltalk-76 by Steve Putz and created for the original Smalltalk-80 by Jim Althoff. Althoff and I were interested in factoring the roles of objects in a way that would support inheritance of roles among three players in any user interface design: the model, its views, and the possible ways in which the user might control or interact with the model and the views. The MVC architecture provides a protocol with which a view or controller declares itself as a dependent of a model and specifies which changes to the model are of particular interest. The MVC framework provides the mechanisms by which change is broadcast to all interested dependents.


12MVC is also documented in the design patterns book (Gamma et al., 1995).

The power of the MVC framework lies in its ability to describe a model without knowledge of particular users of the model, while still allowing the model to be shared among a diverse user community. We were disappointed that the computer science community has focused its attention on whether this should be the trio MVC or just the pair M and V, rather than discussing the value of the proffered factoring. At first, these technologists argued about speed, focusing on control that centered on pointing to and changing graphical views of graphical models, and forgetting that models are not always graphical and might be “viewed” with sound or touch. Second, the technologists argued that for any view, only one preferred controller exists. We provided three parts to the architecture because we believed that more work should be done on different kinds of controllers for different kinds of people, especially for people with visual or hand-skill disabilities that detracted from their ability to use graphical interactive systems.

3.5.3. First Licenses

In 1980, in order to publish the Smalltalk system, we organized a joint project with four other companies: HP, DEC, Apple, and Tektronix. These companies met our requirements for participation: They were hardware vendors with in-house software development teams that could port the Smalltalk-80 system to their companies’ own computers. The deal was simple. The companies received a license to provide Smalltalk-80 version 1.0 on their computers in exchange for commenting on drafts of our book about Smalltalk and porting the virtual machine to test the implementation specification for this book.

It is possible that the decision maker at Xerox agreed to this licensing arrangement because he received advice from a former PARC employee that there was no internal interest. Certainly, such advice was given because we were privy to the written documentation. Seven years later this same decision maker would be instrumental in helping us form an independent company to sell systems based on Smalltalk. Also, seven years later, we had to resolve the paranoia in the growing Smalltalk community that Xerox would sue other vendors of Smalltalk. To create maximum legal comfort and to ensure that Smalltalk was generally available, our commercial company offered licenses for the language itself as well as the class library interface design. Although we tried to provide free licenses, we discovered that we had to charge $1 to create the desired comfort. With the exception of a check from IBM that was never cashed, all licenses were paid in cash, signed by company officers, and framed for my office wall.


Previous Table of Contents Next