Ownership Types for Object Encapsulation

1
Ownership Types for Object Encapsulation

• Authors Chandrasekhar Boyapati
• Barbara Liskov
• Liuba Shrira
• Presented by Charles Lin
• Course CMSC 631

2
A brief digression const

• Consider the following C code

class Foo int x int go(
const Bar bar ) const x
bar.mutate()

• Produces following errors

foo.cpp In method void Foofoo(const Bar )
const' foo.cpp20 passing const Bar' as
this' argument of int
Barmutate()' discards qualifiers foo.cpp20
assignment of member Foox' in
read-only structure
3
The burden of annotation

• Given const errors, what might a programmer do?
• const tells compiler that an object is not
  mutated
• Programmers may ignore this bad!
• Even if programmers dont need to do much
  annotation, they must know what to do

4
Modular reasoning

• Want to reason about programs to perform updates
• Want to reason on individual modules (e.g., a
  Java file)
• Want to avoid interference from objects in other
  modules (e.g., by object encapsulation)

5
Encapsulation

• Goal of encapsulation is to hide implementation
• private hides implementationor does it?
• class Foo
• private Bar b
• public Bar getBar()
• return b // leaks out private data
  member

6
Object Encapsulation

• Want to enforce encapsulation, i.e., cant
  directly access encapsulated objects
• Consider Set class, implemented with ArrayList.

set
o


arrList
7
depends onCriteria for Encapsulation

• Objects often contain subobjects
• Object x depends on subobject s if mutations of s
  affect invariants of x
• Thus, s should encapsulate x

8
Example Set

• Set should encapsulate ArrayList
• If set elements are immutable, then Set doesnt
  have to encapsulate elements.

set
arrList
a
b
c
d
9
Problem with Encapsulation

• Iterators need access to internal representation
  of object

• Solution only allow violations within same
  module (e.g., Java inner classes)

10
Solution Ownership Types

• Allows programmer to declare owners of objects
• If v is owner of s, then outside objects can not
  access s, except possibly through v
• Want to do this check statically

11
Rules for Ownership Types

• Every object has a (single) owner
• The owner can be another object or world
• The owner of an object does not change over time
• The ownership relation forms a tree rooted at
  world

12
Diagram of Ownership Tree
world
o1
o6
o5
o2
o4
o7
o3

• Note ownership is not transitive. o1 owns o2,
  but o1 does not own o3

13
What Can Objects Access?

• Itself and objects it owns
• Its ancestors in the ownership tree, and objects
  they own
• Anything owned by world (recall, no transitivity
  of ownership)

14
How to Annotate

• class TStackltstackOwner, TOwnergt
• TNodeltthis, TOwnergt head
• // Nodes in stack
• class TNodeltnodeOwner, TOwnergt
• TNodeltnodeOwner, TOwnergt next
• TltTOwnergt value
• // Data
• class TltTOwnergt ...

15
What does annotation mean?

• Syntax looks like templates, but contains
  ownership types instead
• First parameter is real owner. Remaining
  parameters pass ownership types to subobjects
• Rule
• Objectlto1, o2, ongt
• o1 lt oi, for 1 lt i lt n
• where x lt y means x is descendant of y in
  ownership tree

16
Example TStack
world
Client
TStack
TNode
T
17
Inner Classes Handling Iterators

• Allow inner classes to break encapsulation
• Inner classes have type annotations just like
  outer classes
• Inner classes do not inherit type annotations
  from outer class

18
Methods can have ownership types

• Allows wrapper objects to have freer ownership
  types than objects they wrap.
• See example with elements() method
• class TStackltstackOwner, TOwnergt
• TStackEnumltenumOwner, TOwnergt
• elementsltenumOwnergt ()
• where (enumOwner lt TOwner)
• ..

19
Encapsulation Theorem

• x can access an object owned by o only if (x lt
  o) or
• x is an inner class of object o
• Proof is due to restrictions placed on ownership
  type parameter list

20
Type Rules

• The proof is left to the interested reader

21
Applications

• Upgrades in persistent object stores TF(x) only
  accesses objects owned by x
• Controlling aliasing
• Data races
• Extension ownership types combined with region
  types

22
Key people in Ownership Types

• Chandrasekhar Boyapati www.eecs.umich.edu/bch
  andra
• Dave Clarke www.cs.uu.nl/people/dave

23
Thoughts

• Annotation Burden? (System uses type inferencing,
  but still requires 1 in 30 lines must be
  annotated)
• Copy constructors? Can one object access
  subobjects of the same type?
• What if we dont care about encapsulation
  everywhere?
• Seems simplewhy are type rules complex?

24
Conclusion

• Ownership types arent magic. As with any type
  system, you must apply them so they are useful.
  
• In particular, you must determine the depends
  on relation to apply ownership correctly.