Index: doc/theses/andrew_beach_MMath/features.tex
===================================================================
--- doc/theses/andrew_beach_MMath/features.tex	(revision bd0bdd372bdc98567b6ae0bc1ddbac1a9052aefc)
+++ doc/theses/andrew_beach_MMath/features.tex	(revision 08e7521543e88f21355a3e37099deb79c718b513)
@@ -147,5 +147,24 @@
 as a hidden field.
 
-\todo{Open/Closed types and how that affects the virtual design.}
+Up until this point the virtual system is a lot like ones found in object-
+orientated languages but this where they diverge. Objects encapsulate a
+single set of behaviours in each type, universally across the entire program,
+and indeed all programs that use that type definition. In this sense the
+types are ``closed" and cannot be altered.
+
+However in \CFA types do not encapsulate any behaviour. Traits are local and
+types can begin to statify a trait, stop satifying a trait or satify the same
+trait in a different way with each new definition. In this sense they are
+``open" as they can change at any time. This means it is implossible to pick
+a single set of functions that repersent the type.
+
+So we don't try to have a single value. The user can define virtual tables
+which are filled in at their declaration and given a name. Anywhere you can
+see that name you can use that virtual table; even if it is defined locally
+inside a function, although in that case you must respect its lifetime.
+
+An object of a virtual type is ``bound" to a virtual table instance which
+sets the virtual members for that object. The virtual members can be accessed
+through the object.
 
 While much of the virtual infrastructure is created, it is currently only used