Nicholas Cameron James Noble Victoria University of Wellington OGJ Gone Wild Nicholas Cameron James Noble Victoria University of Wellington

Ownership Types Partition the heap, etc., etc. Context parameters Familiar ideas Parametricity, substitution, syntactic, static typing, ... But different Parametric dependent phantom types?

OGJ Ownership types can be enforced in Java generics Potanin, Noble, Clarke, Biddle; OOPSLA '06 Ownership types can be enforced in Java generics Type parameters represent context parameters

OGJ Example: class List<X, Owner> { List<X, Owner> next; X datum; } class C { List<Object<World>, This> aList;

OGJ Example: class List<X, Owner> { List<X, Owner> next; X datum; } class C { List<Object<World>, This> aList;

OGJ Example: class List<X, Owner> { List<X, Owner> next; X datum; } class C { List<Object<World>, This> aList;

OGJ Java type system does most of the work The World class is a class like any other

OGJ BUT, This is magic!

OGJ The OGJ type system has special treatment for the This context Not present in Java Mimics the this context in ownership types systems: Cannot be named outside of the class Inside the current object's owner Enforces encapsulation

Let's go wild!

Let's go wild! Wildcards can be used to emulate This Now we don't need any magic – the Java type system does ownership!

Let's go wild! Let's look more closely at the behaviour of This

This Only an implicit link to the this object Can only be named inside a class definition Cannot be named outside Is inside (= subtype of) the owner of the current object Each use represents a unique context

This All these properties can be mimicked using wildcards:

This Can only be named inside a class definition

This Can only be named inside a class definition Use a regular type parameter for This: class List<X, Owner, This> { ... } This can then be used as normal in the class body

This Cannot be named outside

This Cannot be named outside Always use a wildcard to instantiate the type parameter: List<Object<World>, World, ?>

This Is inside (= subtype of) the owner of the current object

This Is inside (= subtype of) the owner of the current object Use an upper bound on This Which will automatically (and implicitly) be inherited by the wildcard class List<X, Owner, This extends Owner> List<Object<World>, World, ?>

This Each use represents a unique context

This Each use represents a unique context This is the behaviour we expect from wildcards: each wildcard hides a (potentially) unique type

Topology vs Encapsulation

Topology Statically describe the structure of the heap Soundness means a reference with a given owner will never contain an object with a different owner

Encapsulation Owners-as-dominators Restricts which objects can hold references to which other objects

Topology Can be enforced simply by using the pattern described earlier This parameter must be instantiated by ?

Topology

Encapsulation Requires all wildcards, except those in the This position, to have lower bounds Similar to JoƎ Cameron, Drossopoulou; ESOP '09 Also all context parameters must be outside Owner Common to ownership types systems

Encapsulation

Still Magic? Extra well-formedness constraint Topology: only pre-processor step Encapsulation: small change to type checker – but not type rules No extra behaviour No extra syntax For the descriptive system – no change to type checking

So what?

So what? We don't actually expect you to program like this But you can if you want to Right now, with a regular Java compiler

So what? Ownership parametricity is exactly the same as type parametricity No magic! Standard type theoretic ideas A step towards better understanding ownership types

Thank you! Questions? ncameron@ecs.vuw.ac.nz