Dynamic Operators

One of the interesting proposed features mentioned in the C# 4.0 CTP documents is operator support on "dynamic". I've done a lot of looking at generic operators in the past, but this potentially allows for a new answer for operators with generics - something of the type:

        public static T Add<T>(T x, T y)
       {
           dynamic xDynamic = x, yDynamic = y;
           return xDynamic + yDynamic;
       }

Unfortunately, the support for operators on dynamic didn't make it into the current CTP bits, so we can't try this yet. But certainly one to watch in the next CTP.

However, looking at the complexity involved behind the scenes with dynamic, I suspect that this isn't going to be nearly as efficient as some of the things you can already do in .NET 3.5 by pre-compiling an Expression to a Func<T,T,T>, like here. A heavily-cut down version of this can be written as follows:

        static class Operator<T>
       {
           private static readonly Func<T, T, T> add;
           public static T Add(T x, T y) { return add(x, y); }
           static Operator()
           {
               var x = Expression.Parameter(typeof(T), "x");
               var y = Expression.Parameter(typeof(T), "y");
               add = Expression.Lambda<Func<T, T, T>>(
                   Expression.Add(x, y), x, y).Compile();
           }
       }

In terms of expression-trees, that is about as simple as they get - but very useful for providing things like operator support. Obviously the code in MiscUtil allows a lot more flexibility ;-p

But! In many cases you aren't going to be doing heavy number crunching... so maybe an occasional dynamic call is acceptable if it reduces some external code. Once the CTP supports it, I will be sure to run a performance test to see where the split lies.

const decimal Tax = 0.175M;

If you're based in the UK, and work on bespoke corporate systems, you are probably having "fun" at the moment. If you are a consultant, you're probably rubbing your hands - but if (like me) you are a salaried employee, you are probably hastily running searches over every piece of code and customer-facing document looking for anything that looks like 17.5, 1.175, 0.175, etc.

Why? A number (essentially: sales tax) that has been constant since 1991 is changing from 17.5% to 15%... in one weeks time (correction: 5 days).

Of course, in a perfect world, every system will get this number from a configuration file, database, etc - but I'm happy to bet that it has snuck into more places than we care to imagine. Time to start paying back that code debt, people...

don't(don't(use using))

I was at DDD day on Saturday, and I was a little surprised to hear a recommendation "don't use using". Now, to be fair: I'm very familiar with the context of this quote - specifically, a handful of classes that do not provide a clean (non-throwing) implementation of IDisposable. But I still don't agree with the advice...

For example, it is fairly well known that WCF makes a bit of a mess in this area... and a complicated mess too. The core ClientBase class throws on Dispose() under a range of fault conditions - with the side effect that you can very easily end up accidentally losing your original exception to a using block.

The recommended workaround here was to not use "using", but to wrap the code manually - something like:

Proxy proxy = new Proxy();
try {
...
} finally {
// lots of code based on state of proxy
}

Now, we could move all the "lots of code" to a static method, but it still makes us do more work that we would like. With WCF, the scenario is further complicated because of the way that proxies work in terms of code-generation - it would be very messy to have to do any subclassing, since you would be subclassing an unknown subclass of ClientBase.

So in this scenario, I would greatly favor encapsulation... an in particular, C# 3.0 extension methods rescue us hugely. Consider we create a common base-class / interface to handle "something we want to dispose but which might explode on us":

public interface IDisposableWrapper<T> : IDisposable
{
 T BaseObject {get;}
}
public class DisposableWrapper<T> : IDisposableWrapper<T> where T : class, IDisposable {
 public T BaseObject {get;private set;}
 public DisposableWrapper(T baseObject) { BaseObject = baseObject; }
 protected virtual void OnDispose() {
     BaseObject.Dispose();
 }
 public void Dispose() {
     if (BaseObject != null) {
         try {
             OnDispose();
         } catch { } // swallow...
     }
     BaseObject = null;
 }
}

Now we can create some extension methods to wrap that for us...

    // core "just dispose it without barfing"
 public static IDisposableWrapper<T> Wrap<T>(this T baseObject)
     where T : class, IDisposable
 {
     if (baseObject is IDisposableWrapper<T>) return (IDisposableWrapper<T>)(object)baseObject;
     return new DisposableWrapper<T>(baseObject);
 }

But more - because extension methods support overloading, we can introduce a WCF-specific extension overload to support clean disposal of WCF clients:

public class ClientWrapper<TProxy, TService> : DisposableWrapper<TProxy>
 where TProxy : ClientBase<TService>
 where TService : class {
 public ClientWrapper(TProxy proxy) : base(proxy) { }
 protected override void OnDispose()
 {
     // lots of code per state of BaseObject
 }
}
 // specific handling for service-model
 public static IDisposableWrapper<TProxy> Wrap<TProxy, TService>(
     this TProxy proxy)
     where TProxy : ClientBase<TService>
     where TService : class
 {
     return new ClientWrapper<TProxy, TService>(proxy);
 }

It might not be obvious, but the generic type-inference actually does all the heavy lifting here; we have a fully wrapped WCF client, regardless of the specific subclass of ClientBase - so we can use:

using (var client = new Proxy().Wrap()) {
 client.BaseObject.SomeMethod();
}

Safe, robust, easy to call, and no code duplication. And extensible to other special cases too.

CF woes

Grumble grumble.

I spent some time on the train this morning scratching my head wondering why some perfectly innocent code was failing in protobuf-net; a user had (quite reasonably) reported the issue, and I was investigating...

Now, I'm not usually a mobile developer, so this might be well known to CF developers - but it was news to me! Here's the setup (after taking out lots of stuff that doesn't matter) - see if you can spot the problem:

static void Foo<T>(T[] values)
{
   List<Wrapper<T>> list = new List<Wrapper<T>>();
   foreach(T value in values)
   {
       list.Add(new Wrapper<T>(value));  
   }
   list.Sort(delegate (Wrapper<T> x, Wrapper<T> y) {
       return x.SomeProp.CompareTo(y.SomeProp);
   }); // BOOM!!!
   // or even just list.Sort();
}

All it does is wrap the values in a wrapper, add them to a list, and sort them by a property of the wrapper (a simple, field-based property - nothing fancy). As it happens, the same thing happens even with just the regular Sort() [assuming you implement IComparable or the generic counterpart].

Looks innocent enough, yes? And it will work in every framework except CF 2.0 - so: can you predict the problem?

It turns out that the CF 2.0 security model is severely, erm.... "interesting" when combined with generics. Even though we don't attempt anything evil via reflection, the above code can throw a MethodAccessException. Well, it was news to me!

The problem is that in CF 2.0, it really, really wants T to be accessible to this method... which means that if Foo and T are in different assemblies, T must be public. Otherwise, even if we don't so much as look sideways at T, the code will fail. And if the type is nested in another type, the containing type must also be public. And so on. Does anybody else smell a fairly large runtime bug here? This pretty much defeats the whole point of "You give me a T (I don't care what), and I know what to do" - with CF 2.0 it is "You give me a T (but please, pretty please, do something that I can't enforce on a constraint), and I might maybe sometimes work without crashing".

The good news is that this is fixed in CF 3.5...

But there you go: if you want to work with generics and library dlls in CF 2.0, then you are probably going to have to make your classes public.

Dynamic Objects, part1

(caveat: all based on the October 2008 public CTP; for all I know, this will be fixed in RTM - but either way, it shows how to work with IDynamicObject)

C# 4.0 / .NET 4.0 introduce DLR concepts into the core framework and language. However, you may-or-may-not know that actually we've had *a* form of dynamic object right from 1.1, in the form of ICustomTypeDescriptor (and TypeDescriptionProvider in .NET 2.0). These are used to provide custom data-binding to .NET objects, and is how (for example) a DataView displays columns in a grid - each column in the DataTable pretends to be a property on the object (each row).

Since C# 4.0 doesn't directly allow you to write dynamic objects, I've been playing with Tobias Hertkorn's dynamic class here.

I was a little surprised to see that this type of custom data-binding doesn't automatically work for dynamic objects (IDynamicObject) - i.e. the following fails:

     dynamic duck = new Duck();
    duck.Value = "abc";
    Application.Run(new Form { DataBindings = {
       { "Text", duck, "Value" } } });

It can't find a property called "Value" on our duck. Vexing. So; what can we do about this? Well, we could try exposing our dynamic object via the standard data-binding API. Of course, we could extend the Duck class to support ICustomTypeDescriptor directly, but I thought it would be more fun (read: challenging) to look at the more general problem of talking to an unknown dynamic object ;-p

To get data-binding working (on objects, rather than types), we need to use ICustomTypeDescriptor:

• IDynamicObject - the dynamic object, which will be wrapped with... 
  • ICustomTypeDescriptor - which provides a... 
    • PropertyDescriptorCollection - which (for each named property) can provide a... 
      • PropertyDescriptor - which exposes... 
        • GetValue
        • SetValue

Most of the code involved here isn't very interesting (I will post it when I find somewhere suitable)... but it presents a few challenges. The main trick here is: given an IDynamicObject and a property name as a string, how do you get/set the value? ILDASM to the rescue, and it turns out to be something like the following (where "getter" and "setter" are used to cache the call-site):

   CallSite<Func<CallSite, object, object>> getter;
public override object GetValue(object component)
{
    if (getter == null)
    {
        var binder = Microsoft.CSharp.RuntimeBinder.RuntimeBinder.GetInstance();
        var payload = new Microsoft.CSharp.RuntimeBinder.CSharpGetMemberPayload(binder, Name);
        getter = CallSite<Func<CallSite, object, object>>.Create(payload);
    }
    return getter.Target(getter, Unwrap(component));
}
CallSite<Func<CallSite, object, object, object>> setter;
public override void SetValue(object component, object value)
{
    if (setter == null)
    {
        var binder = Microsoft.CSharp.RuntimeBinder.RuntimeBinder.GetInstance();
        var payload = new Microsoft.CSharp.RuntimeBinder.CSharpSetMemberPayload(binder, true, null, Name);
        setter = CallSite<Func<CallSite, object, object, object>>.Create(payload);
    }
    setter.Target(setter, Unwrap(component), value);
}

So how do we work with this? I've written a .AsBindable() extension method that wraps an IDynamicObject in my custom type descriptor. We can then bind to the dynamic object as below:

       var duck = new Duck();
    dynamic dynamicDuck = duck;
    dynamicDuck.Value = "abc";
    var bindable = duck.AsBindable();
    Application.Run(new Form { DataBindings = {
        { "Text", bindable, "Value" } } });

Cool ;-p

Next time, I might try and reverse things - i.e. rather than an existing IDynamicObject wrapped in a custom descriptor, I'll try and wrap a regular object (with custom 2.0 data-binding) with IDynamicObject to simplify data-access. Of course, HyperDescriptor would still be much quicker! This is just to play with the objects to see how it all works...

Immutability and optional parameters

(caveat: based on the October 2008 public VS2010 CTP; everything subject to change)

C# 3.0 made it very easy to initialize objects, in particular via "object initializer" syntax. This allows us to set the properties for an object (and child objects) very simply.

I'll give a simple example - but note that this makes a lot more sense where the class has lots of properties... obviously that isn't condusive to blogging, so you'll have to use your imagination ;-p

public sealed class Person {

public string Forename { get; set; }

public string Surname { get; set; }

// snip: other properties

static void Main() {

Person p = new Person {

Forename = "Fred",

Surname = "Flintstone"

};

}

}

In the Main method, we create and initialize the Person via the object initializer, setting the Forename and Surname properties.

OK; all good - but what about immutability? Unfortunately, it starts to break down.

public sealed class Person {

private readonly string forename, surname;

public string Forename { get {return forename; }}

public string Surname { get {return surname; }}

// snip: other properties

static void Main() {

Person p = new Person {

Forename = "Fred",

Surname = "Flintstone"

};

}

}

Error 1 Property or indexer 'Forename' cannot be assigned to -- it is read only

Error 2 Property or indexer 'Surname' cannot be assigned to -- it is read only

The problem is that object initializers work by invoking the setter, which can't happen if there *is* no setter.

Obviously we could add a constructor that sets both the forename and surname, but keep in mind that we might have 10 properties, and different callers might want to set different permutations of properties. We don't really want to add large numbers of constructors to support each caller's whim.

So what about C# 4.0? This introduces optional and named parameters... as well as making COM a lot more friendly, we can use this on our constructors to provide something close to an object initializer:

public sealed class Person {

// readonly fields/properties

private readonly string forename, surname;

public string Forename { get { return forename; } }

public string Surname { get { return surname; } }

// snip: other properties

// constructor with optional arguments

public Person(

string forename = "", string surname = ""

/* snip: other parameters */) {

this.forename = forename;

this.surname = surname;

// snip: other fields

}

static void Main() {

Person p = new Person(

forename: "Fred",

surname: "Flintstone");

}

}

Here, the Main method creates a new immutable Person, specifying just the properties that they want to assign. The rest are defaulted to whatever the "=foo" says in the constructor declaration.

Simple; easy.

Future Expressions

Last post, I looked at what Expression offered in C# 3.5; to re-cap, very versatile at building simple queries, but not useful for writing manipulation code - in particular, the only in-built assignment is via Expression.MemberInit etc, which is useful only when creating new objects - or at a push you can perform a single update by obtaining the setter and using Expression.Call.

The interesting news is that this looks very different in .NET 4.0 (based on the public October 2008 CTP). It appears that Expression underpins much of the DLR / dynamic work - so there are all sorts of interesting new options - essentially, Expression is the new CodeDOM... personally I am very excited about this; I've always found Expression a far more intuitive and workable abstraction than the counterparts.

In .NET 3.5, there are 46 values in the ExpressionType enum; in .NET 4.0 (CTP), this jumps to 69, with options for loop constructs (loop/dowhile/break/continue/yield), member assignment, composite statements (block/comma?), and exception handling.

The new entries (again, based on the CTP) are:

• ActionExpression
• Assign
• Block
• BreakStatement
• Generator
• ContinueStatement
• Delete
• DoStatement
• EmptyStatement
• Extension
• IndexedProperty
• LabeledStatement
• LocalScope
• LoopStatement
• OnesComplement
• ReturnStatement
• Scope
• SwitchStatement
• ThrowStatement
• TryStatement
• Unbox
• Variable
• YieldStatement

I won't pretend to understand them much yet, but I will be investigating! I also understand that the C# 4.0 compiler doesn't support expressions with statement bodies at the moment (although you can build things by hand - which isn't trivial). It will be interesting to see if this changes (not least because reflector is such a good tool for discovering how you are meant to construct these expressions!).

[update] As an example, I previously gave the example of something you can't do in .NET 3.5:

    Expression<Action<Foo>> action = foo =>
    {
      foo.Bar = "def";
      Console.WriteLine(foo);
    };

Well, here it is in .NET 4.0:

   class Foo
   {
       public string Bar { get; set; }
       public override string ToString()
       {
           return Bar;
       }
   }
   static void Main()
   {
       var param = Expression.Parameter(typeof(Foo), "foo");
       var assign = Expression.AssignProperty(
           param,
           typeof(Foo).GetProperty("Bar"),
           Expression.Constant("def", typeof(string)));
       var writeLine = Expression.Call(
           typeof(Console).GetMethod("WriteLine", new[] { typeof(object) }),
           param);

       var action = Expression.Lambda<Action<Foo>>(Expression.Comma(assign, writeLine), param);
       var actionDel = action.Compile();
       Foo foo = new Foo();
       actionDel(foo);
   }

And of course, there are obvious issues with existing LINQ implementations: if you use some of the new constructs, you should expect your legacy LINQ provider to barf; and indeed, most of the new options simply don't make sense for a database call, so we shouldn't expect too much to change in LINQ-to-SQL/EF.