Finishing up on C# 2.0 and moving to 3.0

Hello again,

It's been a while since I posted. The new year's holidays are to blame ! With a rather late happy new year to everyone we'll begin.

In this post, I will be covering Chapter 7 of the book. Chapter 7 finishes up on all the new features in C# 2.0. I won't be covering Chapter 7 in detail since the features are not necessary used that often. On the other hand, it's worth it to know they are there so that when you get into a situation where they can be useful, you know they're there and you can go and read in detail how to use them. So far we have introduced 4 major features with C# 2.0. Generics, delegate improvements, nullable types and iterator blocks. Here is a list of some other features worth mentioning with a brief overview:

• Partial Types: If you have ever used the VS designer to design forms. You have noticed a method in one of your project's classes called InitializeComponents(). You should have never changed the content of this method as it was auto generated by the designer. Having an auto generated part for the code and having manually entered code in the same file is dirty. It would be much better for the designer to write to a single file and then rewrite it whenever it wishes and for the developer to write in an separate file and not have to worry about the auto-generated sections. This is where partial types come into play. They give us the ability to define functionality for a single entity in separate files. At the time of compilation, the compiler would merge all these files into one and create the class. The list of uses go on in the book: Unit tests, dividing a bloated class into smaller functional units, etc. In C# 3.0 we get partial methods. These methods can be defined in the auto generated class and then the manually written class can define functionality for that hook and that functionality is going to be executed as if it was implemented in the auto-generated class. Before partial methods the auto-generated class had to define an event and the manually written one would have to subscribe to it. But this is much more elegant since the hooks that are not used by the manually written file would be deleted during compilation and you wouldn't get a bunch of unused even publishers.
• Static Classes: This feature was introduced to clarify the use of utility classes in the project. Utility classes are common place among projects. Before you had to declare a utility class like so:

      public sealed UtilityClass
      {
          private UtilityClass() {}
          public static Method1()
          {
             ...
          }
          public static Method2()
          {
             ...
          }
      }
      

  The private constructor was to keep others from instantiating your class. Why put it there in the first place ? because the C# compiler by default supplies a public parameter-less constructor with a class that doesn't implement a constructor. It wouldn't do that with a class that has declared one though. That's why we declare one but make it private and empty. The sealed keyword is also there to keep others from inheriting from this class since the static UtilityClass doesn't have anything to specialize since all its members are static. Of course this is all fine and it works. But defining an empty parameterless private constructor is ugly. Also, we can't really keep some from using this class as a type now and a statement like UtilityClass a = null; would run without any compile errors. We want the compiler to do some compile-time checking for us in this case and don't allow such code from compiling. This is exactly what a static keyword in the class definition would do:

      public static UtilityClass
      {
          public static Method1()
          {
             ...
          }
          public static Method2()
          {
             ...
          }
      }
      

  You no longer need to specify the constructor or the sealed keyword. The compiler would also make sure that the class is used properly.
• Different access modifiers for property getter/setter: Before we were forced to have the same access modifier level for both a setter and getter of a property. It is not really uncommon for you to want to be able to change a property in the class itself and not the world outside. This is was not really possible at least without trying to circumvent it with an instance method. In C# 2.0 you can now assign a private setter and a public getter to accomplish the task.
• Namespace aliases: This feature is very useful if you want to use different versions of a type or are using two types that have the same qualified name. You can assign different aliases to their namespace when importing them and use the alias to reference them. For more details on this read section 7.4 of the book.
• Pragma Directives: These are compiler preprocessor commands just like #if, #elif, etc which allow conditional compilation of the code. There are two pragma directives that work with the the Microsoft C# compiler(for other compilers like Mono consult the latest documentation). The two pragma directives are warning and checksum. Warning is used to suppress warnings generated by the compiler and the checksum is used in ASP.net to detect the right source code to debug.
• Fixed-size buffers in unsafe code: These are used to represent unsafe arrays of fixed size. They are mentioned here only for the sake of completeness.
• Friend Assembiles: This feature allows to set an assembly as a friend to another source assembly. This means that the friend assembly has access to all internal members of the source assembly. The only use that Jon thought of is in unit testing where you usually have to set your members to public just to test them. This is kind of ugly because you may forget to set them back. By setting the test class as a friend the test class would be able to test the source class(notice that the class still wouldn't have access to private members).

This concludes covering of Chapter 7. I will cover Chapter 8 in the next post.