Objectives of typed OOP
Instructor's Guide
intro,
types,
algebra,
modules,
classes,
summary,
Q/A,
literature
Before losing ourselves in the details
of mathematical models of types, we must reflect
on what we may expect from a type system
and what not (at least not currently).
From a theoretical perspective our ideal is,
in the words of [DT88], to arrive at a simple type theory
that provides a consistent and flexible framework
for system descriptions
(in order to provide the programmer with sufficient descriptive
power and to aid the construction of useful and
understandable software, while allowing the efficient utilization
of the underlying hardware).
Objectives of typed OOP -- system description
- packaging in a coherent manner
- flexible style of associating operations with objects
- inheritance of description components
-- reuse, understanding
- separation of specification and implementation
- explicit typing to guide binding decisions
slide: Object orientation and types
The question now is, what support does a typing
system provide in this respect.
In slide [8-objectives], a list is given of aspects in which a typing system
may be of help.
One important benefit of regarding ADTs as
real types is that realizations of ADTs
become so-called first class citizens,
which means that they may be treated as any other
value in the language, for instance being passed
as a parameter.
In contrast, syntactic solutions (such as the module
of Modula-2 and the package of Ada) do not allow this.
Pragmatically, the objective of a type system is (and has been)
the prevention of errors.
However, if the type system lacks expressivity,
adequate control for errors may result in becoming
over-restrictive.
In general, the more expressive the type system
the better the support that the compiler may offer.
In this respect, associating constructors with types
may help in relieving
the programmer from dealing with simple but necessary
tasks such as the initialization of complex structures.
Objects, in contrast to modules or packages, allow
for the automatic (compiler supported) initializations
of instances of (abstract) data types,
providing the programmer with relief from an error-prone
routine.
Another area in which a
type system may make the life of a programmer easier
concerns the association of operations with objects.
A polymorphic type system is needed to
understand
the automatic dispatching for virtual
functions and the opportunity of overloading functions,
which
are useful mechanisms to control the complexity
of a program, provided they are well understood.
Reuse and understanding are promoted by allowing
inheritance and refinement of description components.
(As remarked earlier, inheritance and refinement may be regarded as the
essential contribution of object-oriented programming
to the practice of software development.)
It goes without saying that
such reuse needs a firm
semantical basis in order to achieve the goal
of reliable and maintainable software.
Another important issue for which a powerful
type system can provide support is the separation
of specification and implementation.
Naturally, we expect our type system to support
type-safe separate compilation.
But in addition, we may think of allowing
multiple implementations of a single (abstract type)
specification.
Explicit typing may then be of help in choosing
the right binding when the program is actually executed.
For instance in a parallel environment,
behavior may be realized in a number of ways
that differ in the degree to which they affect locality
of access and how they affect, for example, load balancing.
With an eye to the future, these are problems
that may be solved with a good type system
(and accompanying compiler).
One of the desiderata for a type system
for OOP, laid down in [DT88],
is the separation of a behavioral hierarchy
(specifying the behavior of a type in an abstract sense)
and an implementation hierarchy (specifying the
actual realization of that behavior).
Separation is needed
to accommodate the need for multiple realizations
and
to resolve the tension between subtyping
and inheritance (a tension we have already noted
in sections [theme]
and [contracts]).
Remark
In these chapters we cannot hope to do more than
get acquainted with the
material needed
to understand the problems involved in developing
a type system for object-oriented programming.
For an alternative approach, see [Palsberg94].