Mixins in .NET (again)

Colin Angus Mackay — Sun, 10 Aug 2008 23:55:22 GMT

A while ago I wrote about Mixins in C# 3.0, at the time I was saying that you can get some of the functionality, but not all, from some of the new language features in C#3.0. The solution is a bit of a fudge because the language doesn't support the concept. I've been looking at Oxygene recently and it has some language features that go a bit further than C# does and will support greater mixin-like functionality which it calls interface delegation.

Interface delegation is again a bit of a fudge, but not quite like C#. In this case the language supports this mixin-like functionality and the fudge happens in the compiler. Let's take the class hierarchy that I used the last time:

In Oxygene the Dog class looks like this:

interface

type
  Dog = public class(Mammal, IRun, ISwim)
  private
      runInterfaceDelegate : RunMixin; implements IRun;
      swimInterfaceDelegate : SwimMixin; implements ISwim;
  protected
  public
  end;
  
implementation

end.

From this we can see that Dog inherits from Mammal and implements IRun and ISwim. The IRun interface has one method (Run), and the ISwim interface has only one method also (Swim). Of course, there could be as many methods and properties as you like.

The C# version of the Dog class, as produced by Reflector, looks like this:

public class Dog : Mammal, IRun, ISwim
{
    // Fields
    private RunMixin runInterfaceDelegate;
    private SwimMixin swimInterfaceDelegate;

    // Methods
    void IRun.Run()
    {
        this.runInterfaceDelegate.Run();
    }

    void ISwim.Swim()
    {
        this.swimInterfaceDelegate.Swim();
    }
}

As you can see, there are two private fields holding a reference to the appropriate mixin, in each of the methods the responsibility for carrying out the action is delegated to the appropriate surrogate mixin object.

What you will also notice is that you still have to instantiate the surrogate mixin objects. Under normal circumstances that would be in the constructor. If it were a real mixin you wouldn't have the option as the mixin would be created at the same time as the object it is used with. In fact, the mixin would be mixed in as part of the object itself. So, perhaps interface delegates gives you slightly greater power than with a real mixin as you could reuse the surrogate mixin object. Then again, would you want to? I've not been able to think of a scenario where I would, but perhaps it could be useful.

I'd like to see interface delegates in C# at some point in the future (sooner rather than later). In fact, I'd like to see proper mixin functionality, but I recon that will require changes to the CLR to support multiple inheritance. In the meantime, I think I'll have to write some sort of snippet in C# to quickly generate the code that Oxygene gives me in one line. Either that or start writing in Oxygene... Now, there's a thought!

Technorati Tags: Oxygene,C#,interface delegates,mixin

Crazy Extension Methods Redux (with Oxygene)

Colin Angus Mackay — Thu, 07 Aug 2008 20:45:07 GMT

Back in April I blogged about a crazy thing you can do with extension methods in C#3.0. At the time I was adamant that it was a bad idea. I still think it is a bad idea, however, my thoughts have evolved a little since then and I have, possibly a solution to my hesitance to use said crazy feature.

So, if you can't be bothered to click the link, here is a quick recap. You can create an extension method and call it on a null reference and it will NOT throw a NullReferenceException like a real method call would. At the time I was saying it was not best practice because it breaks the semantics of the dot operator which is used for member access.

Last night, I attended an excellent talk by Barry Carr on Oxygene, an Object Pascal based language that targets the .NET Framework. Oxygene has a very interesting feature, it has a special operator for dealing with calls on a reference that might be null. If that language can do it, what's so wrong with the functionality that Extension methods potentially give? Semantics. Notice that I said that Oxygene has "a special operator". It doesn't use the dot operator. The dot operator still breaks if the reference is null. It has a colon operator. In this case if the reference is null (or nil as it is called in Oxygene) then the call to the method doesn't happen. No exception is thrown.

For example. Here is the code with the regular dot operator:

class method ConsoleApp.Main;
var
  myString: String := nil;
begin
  Console.WriteLine('The string length is {0}', myString.Length);
  Console.ReadLine();
end;

And the result is that the NullReferenceException is thrown:

Here is the code with the colon operator:

class method ConsoleApp.Main;
var
  myString: String := nil;
begin
  Console.WriteLine('The string length is {0}', myString:Length);
  Console.ReadLine();
end;

And the result is that the program works, it just didn't call the property Length as there was nothing to call it on:

At this point I really would like to show you what this looks like in Reflector to show you what is going on under the hood, however, I get a message that says "This item is obfuscated and can not be translated" and the code afterwards isn't quite right. However, the crux of it is like this in C#:

int? length;
if (myString != null)
length = myString.Length;
Console.WriteLine("The string length is {0}", length);

Now, back to these extension methods. After seeing this I was thinking that perhaps my total unacceptablity of allowing a null reference to be used with an extension method was perhaps incorrect. In a normal situation with an accidental null reference exception being used the NullReferenceException wouldn't be thrown at the point of the method call (after all, the null reference is actually being passed in as the first parameter in an extension method), but somewhere in the method itself. Normal good practice would place a guard block at the start of the method so that it would be caught immediately.

However, what if you wanted to create similar functionality to the colon operator in Oxygene and have it ignore the null reference and do nothing? Well, my advice would be to create a naming convention for your extension methods to show that null references will be ignored. That way you can get the functionality with a slight semantic fudge of the dot operator. Of course, you still have to do the work and set up guard blocks to handle the null situation yourself in the extension method.

Here's an example:

class Program
{
    static void Main(string[] args)
    {
        string myString = null;
        Console.WriteLine("The string length is {0}", myString.NullableLength());
        Console.ReadLine();
    }
}

public static class MyExtensions
{
    public static int? NullableLength(this string target)
    {
        if (target == null)
            return null;
        return target.Length;
    }
}

Technorati Tags: extension methods,dot operator,colon operator,c#,oxygene,semantics