PLE lecture notes -- Components
Distributing software components, instead of entire
applications, has the potential to benefit everyone:
- Users benefit from being able to assemble applications from
only the best parts, or the ones people are familar with. For example, using
the same "Emacs" component whenever an application needs to do text
editing. This creates a high level of competition and turns software into a
- Developers benefit from not having to develop monolithic programs.
This means a smaller entry cost and shorter release cycles.
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
- Components must be gluable, i.e. reusable
- Glue must bind components
Components must be reusable
The most important characteristic of components is that they are
reusable. Reuse is aided by:
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.)
- 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
- 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.
- Efficiency: the component should adhere to the resource
requirements of the user.
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:
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.
- Reflection: components should dictate the structure of the
glue language. This includes values, types, naming,
effects, and perhaps the reflection mechanism itself.
- 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.
- 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 languages support programming in "interpretive style,"
where data can be interchanged with programs. This includes:
- Generating and executing programs on the fly.
- Storing data as programs which recreate the data when executed.
- Communicating data between programs in the same way.
- Attaching behavior to content, e.g. Web pages.
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.
- minimal structure in the form of declarations
- little concern for efficiency
- many ways to do similar things (in the case of Perl)
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
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.
How To Design
A Scripting Language
PLE Home page
Last modified: Wed Sep 07 16:15:14 GMT 2005