Ownership confinement ensures representation independence for object-oriented programs

Abstract

Dedicated to the memory of Edsger W. Dijkstra.Representation independence or relational parametricity formally characterizes the encapsulation provided by language constructs for data abstraction and justifies reasoning by simulation. Representation independence has been shown for a variety of languages and constructs but not for shared references to mutable state; indeed it fails in general for such languages. This paper formulates representation independence for classes, in an imperative, object-oriented language with pointers, subclassing and dynamic dispatch, class oriented visibility control, recursive types and methods, and a simple form of module. An instance of a class is considered to implement an abstraction using private fields and so-called representation objects. Encapsulation of representation objects is expressed by a restriction, called confinement, on aliasing. Representation independence is proved for programs satisfying the confinement condition. A static analysis is given for confinement that accepts common designs such as the observer and factory patterns. The formalization takes into account not only the usual interface between a client and a class that provides an abstraction but also the interface (often called "protected") between the class and its subclasses.

Observational Purity and Encapsulation

“…Suitable results -analogs of our Assumption 5.1 and Lemma 5.4-are a special case of the theory of representation independence and have been developed for many sorts of languages (Mitchell, 1996;de Roever and Engelhardt, 1998). For Java-like languages, Banerjee and Naumann (2005a) give such a theory under the assumption of suitable alias control which can be achieved using static analysis (Banerjee and Naumann, 2005a;Müller, 2002;Clarke and Drossopoulou, 2002). In these works, alias control is based on the idea that an object "owns" some objects that comprise its encapsulated representations; the static analysis uses annotated types to check that the representation objects are not exposed to clients.…”

“…For couplings of this sort, it is a corollary of Banerjee and Naumann (2005a) that Assumption 5.1 holds, in a Java-like language, for all contexts that respect private visibility. That is, the fact that these fields have private visibility is enough to encapsulate them within the class.…”

“…The val field in Cell is public and could be updated by a client program that obtained a reference to one of these Cell objects. Such a reference could be obtained by the analogous version of procedure leak from Example 4.1; for just this reason, the leak procedure would be rejected by the static analysis in Banerjee and Naumann (2005a) and by ownership type systems (Müller, 2002;Clarke and Drossopoulou, 2002). The representation independence theories say that Assumption 5.1 holds for all contexts that conform to the restrictions of the ownership system.…”

Static Detection of Loop-Invariant Data Structures

“…Ownership types [30,31,32,33,34,35] provide a way of specifying object encapsulation and enabling local reasoning about program correctness in object-oriented programs. While ownership types may be sufficient to select loop data structures and check whether they are confined, these types cannot detect loop-invariant values, which are dependence-related properties.…”

Types for Hierarchic Shapes

“…Representation independence, which means that a class can safely be replaced by another "equivalent" class provided it is encapsulated, i.e., its internal representation is owned by instances of that class, is proven in [4]. In [5] the approach is extended to deal with shared state, recursive methods and callbacks, and the application to program equivalence.…”