ffective use of object technology requires that we clearly specify, in the texts of our
systems, the types of all objects that they will manipulate at run time. This rule, known as
static typing — a notion defined precisely in the next sections — makes our software:
, by enabling compilers and other tools to suppress discrepancies
before they have had time to cause damage.
, by providing precious information to authors of client systems,
future maintainers of our own software, and other readers.
, since this information helps a good compiler generate better code.
Although the typing issue has been extensively discussed in non-O-O contexts, and
static typing applied to many non-O-O languages, the concepts are particularly clear and
relevant in object technology since the approach as a whole is largely based on the idea of
type, merged with the idea of module to yield the basic O-O construct, the class.
The desire to provide static typing has been a major influence on the mechanisms
discussed in earlier chapters. Here we need to take a comprehensive look at typing and
devise solutions to the remaining difficulties raised by this concept.
THE TYPING PROBLEM
One nice thing can be said about the typing issue in object-oriented software construction:
it may not be an easy problem, but it is a
problem — simple, that is, to state.
The Basic Construct
The problem’s simplicity comes from the simplicity of the object-oriented model of
computation. If we put aside some of the details, only one kind of event ever occurs during
the execution of an object-oriented system: feature call, of the general form
which executes on the object attached to
, using the argument
the understanding that in some cases
stands for several arguments, or no argument at
all. Smalltalk programmers would say “pass to the object
”, and use another syntax, but those are differences of style, not substance.
That everything relies on this Basic Construct accounts in part for the general feeling
of beauty that object-oriented ideas arouse in many people.