Tag: .NET 4.0

Bill Wagner has an interesting article on MSDN about implementing Dynamic Objects in C# 4: http://msdn.microsoft.com/en-us/library/ee658247.aspx.  He leaves it up to the reader to figure out the right way to implement the class he describes and provides suggestions.  This is a great way to structure a propaedeutic of this sort, as it affords the clever reader an opportunity to dig into the material on her own.

At the same time, it is often helpful to have a key against which to compare one’s own work.  To that end, the full code required to run the sample application described in the article follows.

Here is the code that serves as our test.  Bill Wagner describes an object that inherits from DynamicObject that will run the following code:

    var newType = new MethodBag();
    newType.SetMethod("Write", () => Console.WriteLine("Hello World"));
    newType.SetMethod("Display", (string parm) => Console.WriteLine(parm));
    newType.SetMethod("IsValid", () => true);
    newType.SetMethod("Square", (int num) => num * num);
    newType.SetMethod("Sequence", () => from n in Enumerable.Range(1, 100)
                                        where n % 5 == 2
                                        select n * n);
    dynamic dispatcher = newType;
    dispatcher.Write();
    var result = dispatcher.IsValid();
    Console.WriteLine(result);
    dispatcher.Display("This is a message");
    var result2 = dispatcher.Square(5);
    Console.WriteLine(result2);
    var sequence = dispatcher.Sequence();
    foreach (var num in sequence)
        Console.WriteLine(num);

    Console.ReadLine();

 

Here is an implementation of MethodBag that will fulfill the expectations established above:

internal class MethodBag: DynamicObject
{
    private Dictionary<string, MethodDescription> methods = 
        new Dictionary<string, MethodDescription>();

    #region Method Descriptions

    private abstract class MethodDescription
    {
        internal abstract int NumberOfParameters
        {
            get;
        }
        internal Expression target
        {
            get;
            set;
        }
        internal abstract object Invoke(object[] parms);
    }

    private class ActionDescription: MethodDescription
    {
        internal override int NumberOfParameters
        {
            get { return 0; }
        }
        internal override object Invoke(object[] parms)
        {
            var target2 = target as Expression<Action>;
            target2.Compile().Invoke();
            return null;
        }
    }

    private class ActionDescription<T> : MethodDescription
    {
        internal override int NumberOfParameters
        {
            get { return 1; }
        }
        internal override object Invoke(object[] parms)
        {
            dynamic target2 = target;
            target2.Compile().Invoke(parms[0]);
            return null;
        }
    }

    private class FuncDescription<T> : MethodDescription
    {
        internal override int NumberOfParameters
        {
            get { return 0; }
        }
        internal override object Invoke(object[] parms)
        {
            dynamic target2 = target;
            return target2.Compile().Invoke();
        }
    }

    private class FuncDescription<T,S> : MethodDescription
    {
        internal override int NumberOfParameters
        {
            get { return 1; }
        }
        internal override object Invoke(object[] parms)
        {
            dynamic target2 = target;
            return target2.Compile().Invoke(parms[0]);

        }
    }

    #endregion

    public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args
        , out object result)
    {
        result = null;
        if (!methods.ContainsKey(binder.Name))
            return false;
        // Described later
        MethodDescription method = methods[binder.Name];
        if (method.NumberOfParameters != args.Length)
            return false;
        result = method.Invoke(args);
        return true;

    }

    #region Set Methods

    public void SetMethod(string name, Expression<Action> lambda)
    {
        var desc = new ActionDescription { target = lambda };
        methods.Add(name, desc);
    }

    public void SetMethod<T>(string name, Expression<Action<T>> lambda)
    {
        var desc = new ActionDescription<T> { target = lambda };
        methods.Add(name, desc);
    }

    public void SetMethod<T>(string name, Expression<Func<T>> lambda)
    {
        var desc = new FuncDescription<T> { target = lambda };
        methods.Add(name, desc);
    }
    
    public void SetMethod<T,S>(string name, Expression<Func<T,S>> lambda)
    {
        var desc = new FuncDescription<T,S> { target = lambda };
        methods.Add(name, desc);
    }

    #endregion
}

 

Your output should look like this:

Hello World

True

This is a message

25

4

49

144

289

484

729

1024

1369

1764

2209

2704

3249

3844

4489

5184

5929

6724

7569

8464

9409

I had a mind-blowing weekend playing with the ExpandoObject in C# 4.0.  When an article appeared on MSDN about it prior to the release of Visual Studio 2010 Beta 2, it looked interesting but not particularly useful.  The ExpandoObject appeared to be merely a property bag that was useful in limited circumstances in which the program flow is aware of the properties being added.  The ExpandoObject is, in essence, a property bag (and also a method bag?) that pretends to be a real type.  With the Beta 1, I tried to bind a WPF Window to it and was quickly disappointed to find that WPF just treated it as a dictionary (which is what it really is) rather than as the typed class it is pretending to be.

With the Beta 2, however, this changed.  The WPF binding stack had apparently been modified to recognize the ExpandoObject and to treat it on its own terms.  If I have a binding on a TextBox in WPF to an arbitrary property called, for instance, “Name”, all I have to do is add that string to the ExpandoObject’s internal dictionary and the value I added will show up in my TextBox.  Even better, the ExpandoObject automatically supports INotifyPropertyChanged on that new pseudo-property.

           dynamic Employee = new ExpandoObject();
           Employee.Name = "Jim Henson";

This small change makes the ExpandoObject suddenly very useful, especially in situations where we need a glue layer between servers and clients that are indifferent to static typing such as an object layer between a REST service and WPF.

Phil Haack has a playful post about this aspect of programming with the dynamic type on his blog: http://haacked.com/archive/2009/08/26/method-missing-csharp-4.aspx .  He prefaces it with this:

Warning: What I’m about to show you is quite possibly an abuse of the C# language. Then again, maybe it’s not. 😉 You’ve been warned.

There’s a lot of truth in this.  On the one hand, dynamic types goes deeply against the grain of anyone who has programmed in C# for the past several years.  I’m not sure how this feels to VB developers who always have had the option to turn Option Strict off in their code.  It gives me the heebie-jeebies, though.

At the same time, it looks extremely fun.  Maybe even a little subversive. I want to start finding applications for this new code feature for working within C# rather than simply using it for interop with supported dynamic languages.

The ExpandoObject does some rather cool things not initially obvious.  For one thing, I can add methods to it as well as properties.  This can be done by passing a delegate to it that references a lambda statement, for instance:

        dynamic obj = new ExpandoObject();

        obj.DoSomething = new Func<string>(() => 
            { Console.WriteLine(DateTime.Now.ToLongTimeString()); return "Hello"; });

        obj.DoSomethingWithParams = new Func<string, bool>((x) => 
            { Console.WriteLine(DateTime.Now.ToLongTimeString());  
                Console.WriteLine(x); 
                return true; 
            });
        Console.WriteLine(obj.DoSomething());
        Console.WriteLine(obj.DoSomethingWithParams("something different"));

Another thing it can do is load properties dynamically (loading a dynamic type dynamically, yeah!) by simply casting it back to the dictionary it really is internally.  Here’s a sample of dynamically loading up an ExpandoObject based on an XML Document:

           XDocument root = XDocument.Load("Employee.xml");
            //convert xml document into an ExpandoObject
           dynamic Employee = new ExpandoObject();

           var EmployeeDictionary = Employee as IDictionary<string, object>;
           foreach (XElement el in root.Elements())
            {
                    EmployeeDictionary.Add(el.Name.LocalName, el.Value);
            }

I now have an object that I can bind to the DataContext of a WPF Window.  I could, of course, have just bound the original XMLDocument to my WPF, but then I wouldn’t have nice extras like INotifyPropertyChanged that I normally expect to have at my disposal in WPF development.

The Dynamic Type is a complicated beast however.  Just reading over Bill Wagner’s post on implementing a Method Bag fills me with anxiety: http://msdn.microsoft.com/en-us/library/ee658247.aspx

That post was nothing, however, compared to this gem I found on Nikhil Kothari’s blog from over a year ago!  http://www.nikhilk.net/CSharp-Dynamic-Programming-REST-Services.aspx

Mr. Kothari builds a class that can point to multiple (and, thanks to the Dynamic Type, interchangeable) REST services and generates properties based on the XML or JSON that comes back.  It does much more than this, also, I think, but Nikhil Kothari is so far beyond me that I have trouble understanding everything that is happening in his code.

The source code, by the way, doesn’t actually compile as it is currently written – but then he did this over a year ago, so…

In any case, walking through and coming to terms with what he has created is certainly one of my goals for November.  It is an implementation that is a game-changer for C# development, and raises Dynamic Types from an oddity to something that will actually solve architectural bottlenecks … at least, I think it does.  As I said, I don’t actually understand it, yet.

C# 4.0 will introduce new language features to help manage covariance and contravariance.  While this is a a wonderful capability, it forces us to come to terms with these (to me) somewhat unfamiliar terms.

As I have been working through Eric Lippert’s excellent series of posts on this topic as well as the wikipedia entry, it has occurred to me that the best way to come to grips with these concepts is to examine gradually more complex examples of covariance and contravariance as it currently exists in C# 3.  If this appears to be a rehash of Eric Lippert’s work, this is probably because it is.  Consequently, any mistakes are purely mine, while any virtues in this explanation are clearly his.

First, however, it is necessary to learn some vocabulary.

Take the following class hierarchy:

        public class Animal{}
        public class Mammal : Animal { }
        public class Tiger : Mammal { }

We would typically say that Mammal is more derived than Animal.  Mammal, conversely, is less derived than Tiger in this inheritance chain.

To understand covariance and contravariance, we need to replace more derived and less derived with the metaphorical terms smaller and bigger.

We do this because more derived and less derived are not adequate to describe the relation between objects such as arrays of types.

        Animal[] A;
        Mammal[] M;
        Tiger[] T;

An array of Mammal does not derive from an array of Animal.  Both Mammal[] and Animal[] are derived from System.Array. There is no inheritance relation, however, between Mammal[] and Animal[] themselves.  Nevertheless there is obviously some sort of relation present.  By convention, we call this relation a smaller than \ greater than relation.  Mammal[] is smaller than Animal[] because Mammal is more derived than Animal.  It is bigger than Tiger[] because Mammal is less derived than the type Tiger.

It is worth repeating that smaller and bigger are not the same thing as the relation between classes in an inheritance hierarchy.  They also do not have anything directly to do with memory management.  They are pure metaphors.

The C# classes above model concepts.  When we talk about concepts such as animal, mammal and tiger, we talk about these concepts falling under each other.  Socrates falls under the concept of man.  Man falls under the concept of an animal (traditionally, man is defined as a bipedal, hairless animal that laughs; see Haecceity).

Metaphorically, we can think of animal as a bigger concept than mammal because many more things fall under animal than under mammal.  Tiger, in turn, is a smaller concept than mammal because so few things fall under it.

Once we have smaller than and bigger than under our belts, we can start talking about covariance and contravariance.  Covariance and contravariance, at the most basic level, concerns the assignment of types to variables.

An assignment is covariant if we can assign a smaller type to a bigger type:

If we can assign a bigger type to a smaller type, the assignment is said to be contravariant:

1. Covariance with simple reference types

An example will help to illustrate this. 

    Mammal m = new Tiger();
    Animal a = m;
    //Tiger t = a;  -- will not compile

We can assign a smaller type, Tiger to a variable allocated as a Mammal.  Similarly we can assign our Mammal instance to a variable allocated as an Animal.  In other words, in the assignment of simple reference types, we can assign smaller things to bigger things.  This is a covariant relation.

We cannot, however, assign an Animal instance to a Tiger.  The C# compiler just won’t let us do it, because it will not let us assign something bigger to something smaller in this case.  The assignment of simple reference types is therefore not covariant.

2. Covariance with arrays

The C# compiler also happens to allow covariant array assignments.  For instance:

    Mammal[] M = new Tiger[0];
    Animal[] A = M;
    //Tiger[] t = A;  -- will not compile

The compiler doesn’t need to allow this.  It just happens to.  What’s interesting is that the compiler will not allow us to do the same thing with generic collections. 

3. Invariance with generics

Assignment of generics is invariant in C# 3.

    // List<Mammal> mammals = new List<Tiger>(); -- will not compile
    // List<Animal> animals = mammals; -- will not compile
    // List<Tiger> tigers = animals;  -- will not compile
    //

4. Covariance with method parameters

Parameter assignment also happens to be covariant in C#.  To prove it to yourself, take the following static method:

     public static void TakeMammal(Mammal m){}

Which of the following operations is permissible in C# and which is not?

    TakeMammal(new Tiger());

    TakeMammal(new Animal());

    TakeMammal(new Mammal());

(Note, however, that ref and out parameters are invariant: http://blogs.msdn.com/ericlippert/archive/2009/09/21/why-do-ref-and-out-parameters-not-allow-type-variation.aspx .)

5. Delegate contravariance with respect to inputs

Understanding this characteristic of parameter assignments is important in order to demonstrate how contravariance occurs in C#.  In C#, delegate assignments are contravariant with respect to inputs.  Consider this code:

 public static void TakeAnimal(Animal a) {}
 public static void TakeMammal(Mammal m){}
 public static void TakeTiger(Tiger t) {}

public delegate void MammalHandler(Mammal m);

MammalHandler funcA = TakeAnimal; //OK
MammalHandler funcM = TakeMammal; //OK
MammalHandler funcT = TakeTiger;  //No!

            funcA(new Mammal()); //OK
            funcM(new Mammal()); //OK
            funcT(new Mammal()); //No!

The delegate method MammalHandler is designed to only take the Mammal type as input.  Any delegate instance – funcA, funcM, funcT – in turn may be passed Mammal objects.  If we pass a Mammal to delegate instance funcA, it ultimately gets passed to our TakeAnimal method.  Since parameter assignments – as we showed above – are covariant, passing a Mammal to TakeAnimal is permissible.  Obviously passing a Mammal to TakeMammal is also permissible.

We cannot, however, pass a Mammal to TakeTiger.  The C# compiler does not allow this.

Consequently, we also cannot assign TakeTiger to our MammalHandler delegate.  Assigning TakeTiger to funcT is illegal.

But in this impermissible delegate assignment, which thing is bigger: MammalHandler or TakeTiger?  MammalHandler, right?  With regard to delegate assignments, then, we are saying that assigning something smaller to something bigger is not allowed.  Assigning something bigger to something smaller, however, is permissible.

Delegate assignments like those above are therefore contravariant.

6. Delegate covariance with respect to return types

I say “like those above” because this is actually true only with respect to delegate inputs.  Delegates can also, of course, return objects – and when they do, this is a covariant relation.  Delegate assignments are said to be contravariant with respect to inputs, but covariant with respect to return types.  You can prove this to yourself by looking through the following code in which the delegate signature has a return value but no parameters.

 

 public static Animal GetAnimal() {}
 public static Mammal GetMammal(){}
 public static Tiger GetTiger() {}

 public delegate Mammal GetMammalDelegate();

 GetMammalDelegate funcA = GetAnimal;  // No!
 GetMammalDelegate funcM = GetMammal;  // OK
 GetMammalDelegate funcT = GetTiger; // OK
 
 

 

So why is this important for understanding C# 4.0?  As we briefly covered above, C# 3 has this peculiar characteristic in that the compiler treats array assignments as covariant operations, but treats the generic assignment of List<T> as an invariant operation. This is obviously a little weird.  In C# 4.0, there will be support for covariance and contravariance in generic interfaces which will allow us to specify how we want our generics to behave – for instance, a special kind of covariant IEnumerable<out T> could be implemented that would provide the sort of covariance now supported for arrays.