Assignment Statement + References = Disaster
                               Bruce W. Weide
                        The Ohio State University
                   http://www.cis.ohio-state.edu/~weide

One of the most important properties a good software engineer seeks is the
ability to reason modularly (a.k.a. "compositionally") about software system
behavior.  If this property holds then summary information about the
behavior of a concrete component -- i.e., its abstract behavioral
specification, as opposed to its implementation code -- can be used to
predict how the component will behave when it is composed with other
components into a larger unit.  Software that does not have the modular
reasoning property is inherently difficult to understand, to reverse
engineer, and to change.

It turns out that the good old assignment statement and the explicit use of
object references ("reference types", "reference variables", "reference
semantics"), which together underpin virtually all imperative and especially
object-oriented programming today, conspire to confound modular reasoning.
Many others have noticed that this is a problem.  But the two standard
suggestions to restore modular reasoning seem unacceptable from the software
engineering standpoint: (1) move from an imperative/object-oriented style to
a pure functional style of design and programming, or (2) further complicate
the imperative/OO programming model with various twists that limit (but do
not eliminate) references.  We will show how to keep software engineers
firmly within an imperative/OO paradigm using only "value types", without
giving up either modular reasoning or efficiency, and while making
surprisingly minor changes to the discipline by which we normally design and
implement component-based software.