Generalized vs. dynamic interfaces
In a comment on “More Haskell in Java 7 or 8?”, I get this question “How does your `Retroactive Interface Implementation’ [in JavaGI] compare with VB9's `dynamic Interfaces?’” Very much appreciated question!
At this point in time (but this might change any time) it is actually a bit difficult to draw a proper comparison, given how little is publically known about dynamic interfaces. It looks like this feature is described, most authoritatively, in the VB9 overview document (from September 2005). Looking at the document (and the single example of dynamic interfaces that it provides), dynamic interfaces cater for the expression of static assumptions (as opposed to statically checked invariants) about the interface of a given object used in late binding (as opposed to static typing) so that “IntelliSense and type inference” can be applied again. A quotation from that document: “A target whose static type is a dynamic interface is always accessed using late-binding, but yet the member access is statically typed. ” The use of `static type’ may be potentially misleading; it is important to note that we are talking about the same kind of static typing as we get for a local variable that is obtained by a downcast from say object. (Clearly, this freewheeling downcast may fail at run-time.) Say, in order for a variable to be of static type I, where I is a dynamic interface, the variable has to be defined by casting some other expression to I.
So dynamic interfaces are tailored for dynamic typing, or strong duck typing, as Erik calls it. The JavaGI proposal does not involve any sort of dynamic typing, but it may be an interesting direction to explore. The VB overview document does not allude to `retroactive interface implementations’. Please check it for yourself. However, I was fortunate enough to be involved in some discussions with VB team members. Also, in a manuscript , Erik Meijer clarifies that dynamic interfaces could allow you to provide implementations separately from classes. He writes “Another proposed extension that aids dynamism are dynamic interfaces that make it possible to implement an interface on an existing type, much like in Haskell we can create an instance of a given type for a type class independent of the definition of that type. ” This is very cool indeed and blends nicely with dynamic typing. I look forward seeing this feature in Orcas, and I am going to miss it in C#. For instance, dynamic interfaces of some form or another would allow us to carry out XML-data binding very much in the LINQ to XSD manner, but without incurring the cost of extra objects for typed views.
So what are the remaining differences between generalized interfaces vs. dynamic interfaces? This really depends on where VB9.0 will land in the end. But I don’t read the VB9 overview document in a way that it takes into account any of the following capabilities of JavaGI:
1. Existential types with implicit pack/unpack.
2. Statically checked virtual interface methods.
3. Self types and binary methods.
4. Multi-headed interfaces.
5. Static interface methods.
6. Default interface methods.
All these capabilities are naturally implied by a transposition of Haskell’s type classes to Java – in fact, except for the first two; they required some extra work. Given that generalized interfaces were defined for Java, I should mention that they should work equally well for C#, and I guess for VB. Despite these differences between generalized interfaces and dynamic interfaces, it is pleasing to see anyhow that both are inspired by Haskell.
There is one peculiar thing about dynamic interfaces that I hope will be fixed in the end. It is about the dynamic contract for `assuming the static type’ of a dynamic interface. That is, when thinking of applications like LINQ to XSD, I find it crucial to be able to check extra pre-conditions at run-time other than just having the run-time system to perform a check for the availability of a more or less retroactive interface implementation. To give a concrete example, when `casting’ an XElement to a customer interface, I want this cast to succeed if and only if the XElement tree exposes the appropriate rooting element label. This leads me to another item for the VB9 wish list. How do I create a customer in the first place? I would need a class Customer. So now I have both a class and an interface for customer. Sigh! Or perhaps the interface customer should have a constructor? So this is a little bit like static methods in JavaGI. I am not sure what the best design would be for VB9.
Other than that, I look forward a type system for dynamic interfaces or a public spec or a publically available reference implementation of dynamic interface. (For instance, the LINQ Preview from May 2006 does not cover dynamic interfaces.) Then we should have this discussion again and who knows, perhaps I am also ready to become a VB programmer. I expect some public stuff to be available soon, but I haven’t asked the VB team for input. (Everyone over here is either recovering from the long power outage we had in the Seattle area, or is busy due to the Xmas period.)
Merry Xmas,
Ralf