DeepFJig - Modular composition of nested classes - Marco Servetto
FJig is a formalisation of the Jigsaw language, which focuses on mixins and 'class' composition. This work extends FJig with an extension to nested classes. I believe that virtual nested classes are the most significant change to the OO paradigm currently being proposed. Being able to abstract and inherit at the level of class families, rather than just individual classes, solves an awful lot of problems with the usual class model. Thus, I'm happy to see another take on the idea.
From what I gathered, DeepFJig only supports 'static' nesting of classes, this makes the type system simple (no path dependent types, or exact types required), but at the expense of a lot of the benefits of virtual classes. The interesting thing here is that by combining nested classes with the mixin composition operators found in FJig, you get a great deal of expressivity - Marco showed how to encode generics (in a virtual types style) and aspects (yes, aspects, as in AOP). This latter probably means that the language is too expressive for some software engineering purposes, but it wasn't clear from the talk how much you can sabotage classes, as you can usually do when using aspects.
Lightweight Nested Inheritance in Layer Decomposition - Tetsuo Kamina
Another nested classes paper, this time extending the 'Lightweight Nested Inheritance' (J&) concept. LNI uses paths of class names and exact class names to identify types. This work extends that with generics so that types can be more precisely specified. However, it seems that you only bite back some of the expressivity lost when compared with systems such as VC and Tribe (which have dependent path types). So, it is a slightly more heavyweight lightweight version of nested class types. The interesting aspect is that type variables can be used as type constructors for path types (but not generics types, i.e., X.C is OK, but X
Mojojojo - More Ownership for Multiple Owners - Paley Li
Paley presented work he has done with James Noble and I on Multiple Ownership type systems. Multiple Ownership was proposed at OOPSLA '07, but the formalisation was unwieldy. This work presents a simpler, more elegant, and more powerful formalisation of the Multiple Ownership concept.
Traditional ownership types systems give each object a single owner, this organises the heap into a tree, which is great for reasoning about programs. Unfortunately, real programs rarely fall nicely into a runtime tree structure, so more flexible ways to organise the heap are required. Multiple Ownership allows each object to be owned by multiple owners, thus organising the heap into a DAG.
Mojojojo (if you don't get the name, Google for the Powerpuff Girls) adds a powerful system of constraints over the structure of the heap, generics, existential quantification, and a host of small improvements to the formal system, resulting in something a lot nicer than MOJO. Paley gave a great talk, and I recommend you all read the paper (totally unbiased opinion, of course :-) ).
Interoperability in a Scripted World: Putting Inheritance & Prototypes Together - Kathryn E. Gray
I'm sorry I cannot write more about this paper, because it sounds really interesting, but I was a bit distracted at the beginning of the talk, and never quite got back into the flow. I'll be reading the paper later though...
Adding Pattern Matching to Existing Object-Oriented Languages - Changhee Park
Changhee talked about adding pattern matching to Fortress (which reminds me to check on what is happening with Fortress nowadays). In fact one of the more interesting bits of the talk was the generalisation - the requirements on a language such that it can support pattern matching in the way described.
The general idea of the work is to support ADT-style decomposition of types by subtype using a typecase expression and function parameters and decomposition of objects into its fields, similarly to how tuples are decomposed in Python etc. What I thought was missing was a discussion of whether or not you would actually want to do this: you are breaking object-based encapsulation, which most languages avoid.