PLE lecture notes -- Components

Component software

Distributing software components, instead of entire applications, has the potential to benefit everyone:

In order to build applications out of independently-engineered parts, we not only need components but also glue to hold them together. It is important to distinguish glue because components and glue have to satisfy different requirements. These arise from two simple facts:

Components must be reusable

The most important characteristic of components is that they are reusable. Reuse is aided by:
  1. Generality: the component must support various uses. The linguistics lecture discussed some approaches to generality: polymorphism, higher-order functions, and inheritance. A component should be able to adapt to its embedding environment, e.g. in its naming (whether names denote variables or methods) and control flow (whether it is called as a subroutine or coroutine).
  2. Contracts: the component should ensure that it is correct, and that it is used properly. Typing, encapsulation, invariants, and run-time instrumentation are ways to do this.
  3. Efficiency: the component should adhere to the resource requirements of the user.
Thus Sather, Haskell, and C++ might be useful languages for writing components. However, it is unrealistic to expect that all components be written in a single language. Different tasks still have different language requirements, besides those specific to components, e.g. abstraction, parallelism, and simplicity. A single language which attempts to meet many different requirements is difficult to engineer, and the result is a monolith. (Software tools are applications, too, and so should also be designed in terms of components. With more competition among languages, instead of language monopolies, all of this research may actually see the light of day.)

Glue must bind components

The most important characteristic of glue is that it support many different kinds of components. Since components should be written in several languages, this includes inter-language unification. It also means that the glue language must be extensible. Component binding is aided by:
  1. Reflection: components should dictate the structure of the glue language. This includes values, types, naming, effects, and perhaps the reflection mechanism itself.
  2. Naming: a powerful naming system is needed to manage components and allow them to refer to each other. It should support modular namespaces which avoid name capture or name clash.
  3. Constraints: glue must manage relationships between components. Declarative statement of constraints is more convenient than message-passing for this purpose, and is often more efficient.


Interpreted scripting languages are sometimes presented as glue languages. By binding commands in the language to component functions, it is easy to build applications. (Tcl/Tk is a good example.) However, while useful for many tasks, the features of these languages seem to have little in common with the goals outlined above.

Interpreted languages support programming in "interpretive style," where data can be interchanged with programs. This includes:

Scripting languages are optimized for short, simple, used-once programs. Their goal is to enable good things rather than prevent bad things. This includes:

These are all consistent with the objective of scripting, but this is not the same as component software.

Recently, scripting languages have been outfitted with better naming systems (e.g. Perl5) and reflection capabilities (e.g. Python), which make them better glue languages. However, the best glue languages may result from assuming the glue requirements as fundamental, not add-ons.

Other reading

David Canfield Smith and Joshua Susser. A component architecture for personal computer software. In Languages for Developing User Interfaces, ed. Brad Myers, Jones and Bartlett, 1992.

Michael Floyd. The evolution of component-based programming. Dr. Dobbs Journal, 16(1):96--98, January 1991.

Brad J. Cox. There is a silver bullet: a software industrial revolution based on reusable and interchangeable parts will alter the software universe. Byte, 15(10):209--215, October 1990.

OpenDoc . ILU . CORBA . Guile .
How To Design A Scripting Language

PLE Home page
Last modified: Wed Sep 07 16:15:14 GMT 2005