More on C# Dynamic Programming

Just wanted to share this article on C# dynamic programming from DevFusion.  It explains the difference between anonymous types and dynamic programming.  Don’t get too caught up on the opinions of the author Mike Jones.  Whether you agree with him or not this is a great explanation of using the dynamic keyword in C#.

Enjoy!

Silverlight 3 Jumpstart Book

Just wanted to let everyone know that my employers and friends Dave and Julie Yack have done it again.  They have published another book.  This one is a 200 page jumpstart to the recently released Silverlight 3.  I helped do some tech editing of the book the last couple weeks and I can say it is really good for getting started with Silverlight.  Read more about the release on Julie’s blog here.  You can also get some more details about the book at the books website http://silverlightjumpstart.com/Default.aspx or on Amazon.

Happy reading….

Dynamic Programming with C# 4.0

Yesterday Joe Mayo talked to the South Colorado .NET User Group about the new features of C# 4.0.  The most interesting change is the addition of the “dynamic” datatype.  This datatype allows developers to declare a variable that is not actually typed until runtime.  This is different than the “var” keyword which actually types the variable using the return value from the right side of the equals sign.  Let’s take a look at a quick example:

   1: private void Main()
   2:         {
   3:             Dog thisDog = new Dog();
   4:             AnimalSpeak(thisDog);
   5:  
   6:             Cat thisCat = new Cat();
   7:             AnimalSpeak(thisCat);
   8:  
   9:             Frog thisFrog = new Frog();
  10:             AnimalSpeak(thisFrog);
  11:  
  12:             Bird thisBird = new Bird();
  13:             AnimalSpeak(thisBird);
  14:         }
  15:  
  16:         private void AnimalSpeak(dynamic Animal)
  17:         {
  18:             Animal.Speak();
  19:         }
Notice on line 16 the parameter uses the dynamic datatype.  This allows us pass in any object and try to call the Speak method.  Also take notice we are not using an interface to ensure there is a Speak method on the object.  So, we lose the benefits of strong typing and if the object passed in does not contain a Speak method we get a run time error. 

The dynamic datatype is very powerful, especially when it comes to dealing with COM interop.  It also will aid test driven development (TDD) by allowing developers to write unit tests without worrying about the actual implementation of the objects they are testing until after the tests are written.  Again very powerful.

However, with great power comes great responsibility.

I feel that there are a couple issues with dynamic programming.  It seams we have come full circle with .NET.  I remember when .NET first came out and everyone was promoting type safety as a huge benefit.  Now with dynamic programming we can bypass type safety and just wing it. One problem I have with this is that the errors are runtime errors.  So, for example lets say we are accessing a COM object dynamically.  In our dev environment we have a the new version of the COM object that supports some new functionality we are using.  If we move the application to test or prod and forget to upgrade the COM object, the application may start and run without a problem but will bomb at runtime whenever a user tries to access that one section of our app that is using the new functionality.  To me this puts too much emphasis on QA testing when the application still compiles but may bomb at runtime.

Another disadvantage of dynamic programming is the lack of intellisense.  If you declare the variable as dynamic then intellisense will not work.  Again, this opens up the issue of misspelling some of the properties or methods that will not get caught until runtime.  I really like intellisense so I will not use dynamic unless it is the last option.

My fear is that many developers will get lazy with dynamic programming and use it in the wrong situations.  Using it as a replacement for using interfaces or good old fashion reflection may cause more runtime issues that slip past testing and hit production users.  Some developers may see that as job security.  I see it as a sure fire way to lose customers.