In part 1 of the "What's New in C# 3.0" series we are taking a look at partial methods and automatic properties. These are pretty simple so it should be an easy start for everyone. However before that I would like to tell you about the concept behind the new things in C# 3.0.

  Anders (Hallowed be his name) has this vision that the future of programming is closely related to the methods of representing data. The most common way of representing data today are relational databases but data also comes in XML and many other formats. He believes that programming platforms should provide not only tools for better integration of data (like ORM Frameworks) but also programming language features for integrating data. Anders (Hallowed be his name) designed a mechanism for handling data in C# called LINQ. It is supposed to handle different data (i.e. database, XML, etc.) in the same way using the same syntax.  To implement LINQ he needed some .NET Framework features and some language features. The framework features were added with .NET 2.0. These were nullable types, generics and anonymous methods. These features proved very useful for non-LINQ, C# 2.0 code but their real power is revealed with C# 3.0 and LINQ. .NET 3.0 and .NET 3.5 both run on Common Language Infrastructure (CLI) 2.0. Anders (Hallowed be his name) being the genius that he is planned everything 3+ years in advance.  In C# 3.0 he added more features closely related to LINQ. All these features were supported by CLI 2.0 so the only thing that had to change was the C# compiler. When designing the new features Anders used a simple principle. In order to get in the language, a feature should be useful out of LINQ context. In my articles I am gonna examine every feature out of the LINQ context and in the end we will see how everything works together in LINQ.

   Lets enter the world of C# 3.0 with Automatic properties. In C# 2.0 you have to write properties of a class like this

class Mlass
{
   private int mint;

   public int Mint
   {
        get { return mint; }
        set { mint = value; }
   }

   private string mring;

   public string Mring
   {
        get { return mring; }
        set { mring = value; }
   }

  // more of the same
}

  This is quite trivial and it is the most common scenario. Visual Studio helps us with some templates but it is not as good as Java IDEs with their “generate accessors” feature. However we are lucky to have Anders (Hallowed be his name) to save us. He is open-minded and not shy to put new features in the language (by contrast Java designers are VERY conservative). Now we got this pretty new syntax for writing this most common properties:

public int Mint { get; set; }

  We do not even need the IDE to help us because it is so short. What we did was creating a property without an underlying field. The cool thing is that by contract this is still a property so if we decide to expand it we can always replace it with old-style get/set with code and an underlying field. The logical question is "How did the C# compiler do that?". The answer is also logical. It did the same thing it does when compiling old-style get/set. In the compiled IL code there is a field and the two methods (remember properties are actually get and set methods under the hood). The field is not accessible to us even from within the class but it is there(I checked with ildasm :) ). You cannot have get-only or set-only automatic property. If you think about it you will find out why. Lets see who will be the first to point out the obvious in the comments.

  Partial methods are methods that can be declared in one file from partial class and implemented within another. This is very similar to C style prototypes though they serve very different purpose. Declaration looks like this:

partial void Method(int mint); //fuck I can't replace the first letter in Method with M

and implementation looks like this:

partial void Method(int mint)
{
   Console.WriteLine(mint);
}

  If no body is provided for partial methods the compiler just ignores them as if they do not exist. Nothing is put in the compiled code. This brings several limitations. Because partial methods can be removed from the code they should be limited to signatures that are not required to the code to be compiled correctly. Thus they should always return void, they are implicitly private and they cannot have out parameters (they can have ref parameters though). This guarantees that removing them will not affect the compilation because no other method expects the return value and no client code can call them. The logical question here is “What are these partial methods good for?”. With so many tools that generate code we need some way to plug into the generated code without changing  it because if we need to regenerate the code our changes will be lost. This was the reason for introducing partial classes in C# 2.0. C# 3.0 takes this further. The tool can put partial method calls in selected places and leave the implementation to the programmer. If the programmer does not implement it – fine. The compiler just ignores it. We will see this in use when (if) we get to the LINQ to SQL generation. All tools that generate code can benefit from this feature and not only LINQ related.

Cya and stay tuned for part 2.