I love explicit interface implementation in .NET, where a method defined on an interface can only be called through a reference to that type.

	public interface IFoo {
		void DoFoo();
	}

	public class Bar : IFoo {
		void IFoo.DoFoo() {
			...
		}
	}

This forces Bar clients to program against the IFoo interface, which makes implementation substitution an easy process. Sounds good so far? It is, until I want to call DoFoo() from within Bar. Instead of making a regular call to

	DoFoo();

Or even

	IFoo.DoFoo();

I have to go to the trouble of casting 'this' to IFoo

	(this as IFoo).DoFoo();

Under the covers, the explicit interface implementation method is compiled as a private method with the name interfaceName.methodName. The code I use to call this (above) corresponds pretty well to the IL that I need to invoke the method, but it seems like a little bit of extra typing. Can't the compiler do this for me?

I spent this afternoon with Chris Anderson (Avalon) and Don Box (Indigo) at a round-table for MVPs and a couple of hard to classify hangers-on (which captures me). The big take home for me was Don's line "Come for Avalon, stay for Indigo", which is to say I didn't get much out of it.

The discussion tended to bog down on topics like "Who will buy longhorn?" and "Is anyone willing to pay for software nowadays?". These big, vague and obvious questions really glaze my eyes over, so I spent a lot of the time staring at Don's boat shoes and wondering why he wasn't wearing socks.

I managed to provoke the great man himself when I asked why Visual Studio's asmx development is type-first (vs. schema-first), given the potential for later versioning pain, developer misunderstanding etc.

Don's response was something like: I don't know you, but I'm willing to bet you don't understand schema very well, so you are better off leaving it to us. So my tenuous claim to fame is that a famous developer doesn't know me, but just from looking at me, he doesn't think I'm very smart. A red letter day.

As an adjunct to my note about static methods on interfaces, these obviously aren't CLS compliant. I've had some discussions with development partners recently who really want to develop CLS compliant code.

Does anyone actually care about CLS compliance? I suspect this is relevant for a very small percentage of developers - most organisations aren't writing for reuse outside their organisation. And many of those that are will probably be looking to other type systems for surfacing their code. So who cares?

After playing around with gpcp recently, I decided to read John Gough's Compiling for the .NET Common Language Runtime again. I found something interesting in there that I missed the first time around: interfaces can implement static methods and fields. This appears to be another interesting feature that is not supported by mainstream msft languages, but is available. The IL looks like:

.class public interface InterfaceWithStatic {

	.method public static void StaticMethod() cil managed {
		ldstr "hello from static method on interface"
		call void [mscorlib]System.Console::WriteLine(string)
		ret
	}

}

So this makes it on to my list of .NET party tricks, along with global methods and throwing non-exception types.