Immutability - ECS | Victoria University of Wellington

246 A. Potanin et al.
distinction one could easily create an example where a mutable alias can be returned
from a read-only object.
4.4 Complementing Immutability
In this subsection we explain why blindly adding immutability support to any OO language
with aliasing might not be such a good idea and how it can be addressed by
careful application of various ownership techniques discussed in the rest of this book.
Boyland [45] criticizes existing proposals for handling read-only references on the
following points:
1. Read-only references can be aliased, for example by capturing a method argument;
2. A read-only annotation does not express whether
(a) the referenced object is immutable, so the referent is known to never change;
(b) a read-only reference is unique and thus effectively immutable;
(c) mutable aliases of a read-only reference can exist, which makes possible observational
exposure, which occurs when changes to state are observed through a
read-only reference.
Essentially, Boyland is criticizing reference immutability for not being object immutability.
In some contexts, object immutability is more useful, and in other contexts, reference
immutability is more useful. Furthermore, as we noted earlier, different contexts
require other differences (such as representation immutability for reasoning about the
memory system, and abstract immutability for reasoning about client code semantics).
Boyland’s criticisms can be addressed, for those contexts where object immutability is
desired, by augmenting reference immutability with object immutability.
For example, Joe 3 addresses all of these problems. First, Joe 3 supports ownerpolymorphic
methods, which can express that a method does not capture one or more
of its arguments. Second, owners are decorated with modes that govern how the objects
owned by that owner will be treated in a particular context. Together with auxiliary
constructs inherited from Joline [46], the modes can express immutability both in terms
of 2.a) and 2.b), and read-only which permits the existence of mutable aliases (2.c).
Moreover, Joe 3 supports fractional permissions [47] — converting a mutable unique
reference into several immutable references for a certain context. This allows safe representation
exposure without the risk for observational exposure.
OIGJ and Joe 3 allow both read-only references and immutable objects in the same
language. This provides the safety desired by Boyland’s second point, but also allows
coding patterns which do rely on observing changes in an object. In order to support
such flexibility it appears necessary to employ some kind of alias control mechanism,
which in the cases of OIGJ and Joe 3 is ownership.
Ownership and Immutability. Ownership types [40, 48] impose a structure on the
references between objects in the program heap. Languages with ownership, such as
for instance Joline [46] and OGJ [49], prevent aliasing to the internal state of an object.
While preventing exposure of owned objects, ownership does not address exposing immutable
parts of an object which cannot break encapsulation, even though the idea was
originally sprung out of a proposal supporting that [30].