I am going to publish a series of blogposts that intend to bring C# 3.0 down to earth. C# 3.0, along with LINQ, and all the heavy duty talk that surrounds it has sort of made it difficult to understand IMO. Well - if not difficult to understand, it sure is tough to gauge - "Where to begin".So with 5 minutes a day, a short post a day will dice and slice a single feature, and we will logically move to a fuller picture of C# 3.0, followed by LINQ, and DLINQ (if I still have steam left).So here we go, with the first in that series, the "var" keyword.In C# 2.0, you can declare an integer (or anything for that matter of fact) as - int i;You could also write something like - int i = 1;Generally speaking -
Part 2: Anonymous Types
In my last blog entry, I had talked about Implicitly typed local variables and the "var" keyword. If you have stumbled across this post through a search engine, or otherwise, I would recommend reading that first.Assuming that you understand "var" - lets dive into part 2 of Demystifying C#3.0 ~ Anonymous Types.In C# 2.0, lets say you wanted to represent a person, you would typically have to write a class as follows -public class Person{ string hairColor ; string skinColor ; int teethCount ;} // I'm obviously taking the shortcut by not creating properties .. anyway, that's besides the point.Well, in LINQ, I could be querying arbitrary groups of my data. When I'm querying "Customers", and the above is a subset of "a customer" - what a royal pain in the rear it would be if I had to first write the structure of my class, before I can use the class? (Duh!). While that sounds like "the thing to do" - you immediately lose the ability to query any arbitrary structures of data at runtime.Enter anonymous types. Now you can represent arbitrary clumps of data, without having to declare their structure first. Here is how.var monster = new {hair="black", skin="green", teethCount=64} ;The above line of code will work even if you do not declare a class called "Person" in advance. This lets you arbitrarily create newer structures to represent your data, without having to define them at "coding time" first.The above line of code simply generates a class under the scenes (you never see it), that looks like as below - class __Anonymous1{ private string _hair = "black"; private string _skin = "green"; private int _teeth = 64;
public string hair {get { return _hair; } set { _hair = value; }} public string skin {get { return _skin; } set { _skin = value; }} public int teeth {get { return _teeth; } set { _teeth = value; }}}Thus this class is an "Anonymous Type" - it has no name, it was generated for you by the C# compiler, so you can represent and hold any arbitrary clump of data, but yes it is a "System.Type".The rationale behind the creation of this was to be able to query for any arbitrary set of data, without having to declare it's structure first. That would be a bit essential for LINQ I'd say ;-).
Part 3: Extension Methods
If you've been following my blog, you would have noticed that I've been trying to talk about new C# 3.0 features one by one. I am trying to take the technical jargon out, and bring these features down to an understandable level.
You may want to read the two features I have already talked about below -
a) Demystifying C# 3.0 - Part 1: Implicitly Typed Local Variables "var"b) Demystifying C# 3.0 - Part 2: Anonymous Types
So here goes, Part 3: Extension methods.
Frequently you are handed a class, such as System.String, or System.Int32, that you "wished" had that one extra method that would make your life so much easier - but damn it doesn't have that method. In certain instances you can inherit and add, but you know that is tougher than it sounds in many cases (abstract/virtual), and in certain cases impossible (sealed).
Extension methods, solve that problem. You can now add newer methods, specific to your business domain - to existing types, that you did or didn't write.
So if you wanted an extra method called "SpankMonkey", you could now write code like below
int i = 10 ;i.SpankMonkey() ; // Spanks the monkey per the logic you wrote.
How neat !!! But don't go around misusing this *feature*, because Extension methods are both less discoverable and more limited in functionality than plain vanilla instance methods such as ToString(). Use them only if you must.
So how do you write an extension method?
Well thats easy, you simply put the "this" keyword as the first parameter of the extension method ~ which is a static method in a class. So you could write code as below
public static class myExtensions{ public static void SpankMonkey(this int i) { Console.WriteLine("SPANK!!"); }}
Sure you could have complicated implementations such as -
public static int DoubleMe(this int i){ return i + i ;}
You could call the above using -
int i = 10;Console.WriteLine(i.DoubleMe()) ; // Prints 20
You could also pass in a "generic" instead of an "int" or "string" etc.
Extension Method Resolution:
An obvious question here is, what if your class implements a method, AND there is an extension method that looks, talks, walks the same way - that is of the same name? Which gets called?
The answer is - "Whichever is the closest". In other words,
Strongly Typed instance methods _will_overrule_ Strongly Typed extension methods _will_overrule_Not Strongly Typed instance methods _will_overrule_Not Strongly Typed extension methods.
Whoaa that's confusing. :)
This code makes it easy to eat the above 4 lines.
public static class E{ public static void F(this object obj, int i) { } public static void F(this object obj, string s) { }}
public class A { }
public class B
{
public void F(int i) { }
}
public class C
{
public void F(object obj) { }
}
public class X
{
public static void Test(A a, B b, C c)
{
a.F(1); // E.F(object, int) is called
a.F("hello"); // E.F(object, string) is called
b.F(1); // B.F(int) is called
b.F("hello"); // E.F(object, string) is called
c.F(1); // C.F(object) is called
c.F("hello"); // C.F(object) is called
}
}
Of course if nothing matches, you get a compile time error (duh!)Neat !! So now we know what "Extension methods" are, how you can write them, how you can use them, and how they may be called.Next we'll be talking about Lambda Expressions. See ya around !! :-)
Part 4: Lambda Expressions
In the Demystifying C# 3.0, I've already talked about -
a) Demystifying C# 3.0 - Part 1: Implicitly Typed Local Variables "var"b) Demystifying C# 3.0 - Part 2: Anonymous Typesc) Demystifying C# 3.0 - Part 3: Extension Methods
Lets next talk about Lambda Expressions.
The best way I can describe Lambda Expressions are - C# Anonymous Methods, only a lot cooler.
So what is an anonymous method in C# 2.0?
Well y'know you can write code like below in C# 1.x/2.x -
class SomeClass{ delegate void SomeDelegate(); public void InvokeMethod() { SomeDelegate del = new SomeDelegate(SomeMethod); del(); }
void SomeMethod() { Console.WriteLine("Hello"); }}
Well, anonymous methods let you write the above code in a much more "convenient to write terse way" as below -
class SomeClass{ delegate void SomeDelegate(); public void InvokeMethod() { SomeDelegate del = delegate() { Console.WriteLine("Hello"); }; del(); }}
Wunner'ful. What you see above after the "delegate()" stuff is an anonymous method. Even though it's better than the C# 1.x version, it is still quite verbose.
Lambda expressions give you an even more concise, functional syntax using the"=>" token. In fact, the above could now simply be written as
class SomeClass{ delegate void SomeDelegate(); public void InvokeMethod() { SomeDelegate del = () => Console.WriteLine("Hello") ; del(); }}
In general, the syntax is
parameters => expression
Now obviously, even though this is terse, frankly I don't know how you feel about it - I think changing syntax just for the heck of it, dude that's so not cool!! Now it turns out, Lambda expressions aren't simply a cool new way of writing anonymous methods. They are in fact, a functional superset of anonymous methods. Why?
· Lambda expressions can "infer" parameter types, even if you omit them. Anonymous methods bitch and moan if you miss out any parameter explicitly.
· Lambda expressions can use both statement blocks and expressions. Anonymous methods take only statement blocks - thus making lambda expressions a tad bit more convenient to use.
· Lambda expressions can be passed in as arguments. And when you do so, they participate in "Type argument inference" and "method overload resolution" - (WHOAA what are these 2 heavy duty sounding words? - Sit tight, we'll talk about them soon-ish).
· Lambda expressions with an expression body can be converted into expression trees. Expression trees is .. well, we haven't discussed that yet ~ so we'll discuss that, when I write a blogpost about Expression Trees.
Lets talk about these one by one -
Lambda expressions can "infer" parameter types, even if you omit them. Anonymous methods bitch and moan if you miss out any parameter explicitly.
Heavy duty words for something as simple as -
(int x) => x + 1 ; // is the same asx => x + 1 ;
In the second instance, the type is being inferred.
Lambda expressions can use both statement blocks and expressions. Anonymous methods take only statement blocks - thus making lambda expressions a tad bit more convenient to use.
Again, heavy duty words for something as simple as -
(int x) => x + 1 ; // is the same as(int x) => { return x + 1; }
In the second instance, we have a statement block, and in the first we have an expression. So the first - is the same as the below, but it is terse and easier to write and understand.
Lambda expressions can be passed in as arguments. And when you do so, they participate in "Type argument inference" and "method overload resolution"
You could pass in Lambda expressions as arguments into a generic method. Lets consider this in an example. Lets say, you had an extension method (what are extension methods?) as shown below -
public static class myExtensions{ public static void SpankIt
You could use the above Extension method a bit like this -
static void Main(string[] args){ List
And this produces "SPANK MONKEY !!" twice.
But wait a minute. What is "U" in the extension method? If you put a breakpoint in your extension method, you will find out that C# 3.0 is smart enough to infer that "U" is a string. Dude, you never said "String" it "inferred" it based upon what lambda expression you passed in.
You can't do that with anonymous methods, now can you?
Overload resolution is very similar to this, so I will skip explaining that. And yes there are clear laid out rules regarding overload resolution and type-inference, refer to the C# specs for that (I hate regurgitating docs).
Finally -
Lambda expressions with an expression body can be converted into expression trees. Expression trees is well just read this post instead.
Part 5: Object and Collection Initializers
As you may already be aware, I am writing up a series of posts on C# 3.0/LINQ and DLINQ, that intend to bring these technologies down to a simple, easy to digest, understandable form. These will be served in small bite sized peices - 5 minutes of your time everyday, and little strokes will fell great oaks. (I am still talking about C# 3.0)
So in this series, we have already talked about -
a) Demystifying C# 3.0 - Part 1: Implicitly Typed Local Variables "var"b) Demystifying C# 3.0 - Part 2: Anonymous Typesc) Demystifying C# 3.0 - Part 3: Extension Methodsd) Demystifying C# 3.0 - Part 4: Lambda Expressions
Today, lets talk about "Object and Collection Initializers"
First Object Initializers
Lets say, you had a class as shown below -
public class Monkey{ private string monkeyName; private int age; public string Name { get { return monkeyName; } set { monkeyName = value; } } public int Age { get { return age; } set { age = value; } } }
The above can be easily instantiated as shown below -
var gwBush = new Monkey{ Name = "George W Bush", Age = 16} ;
The above code simply calls the "setters" of "Monkey" to give you a variable called gwBush back. Note that there is no constructor that accepts the public properties as arguments.
Next, Collection Initializers
Collection initializers, are the corollary of how you'd initialize arrays. Put simply, you can initialize a collection as shown below -
List
So what is the practical upshot of this?
Look at this one line of code -
var theWhiteHouseStaff = new List
Boy that sure looks a lot cleaner than a number of temporary variables, hanging chads and recount in florida etc. .. in other words, a much cleaner and terse syntax
Part 6: (LINQ) Query Expression Translation (to C# 3.0)
In this series of Demystifying C# 3.0 we have already covered -
a) Demystifying C# 3.0 - Part 1: Implicitly Typed Local Variables "var"b) Demystifying C# 3.0 - Part 2: Anonymous Typesc) Demystifying C# 3.0 - Part 3: Extension Methodsd) Demystifying C# 3.0 - Part 4: Lambda Expressionse) Demystifying C# 3.0 - Part 5: Object and Collection Initializers
I *strongly* recommend reading up the above in sequence before reading this post. This is, (I feel) a rather good post, that will set LINQ in your mind clearly. If you rush through this post, you will waste this opportunity. If you are crystal clear about the above 5 posts and the concepts behind them, .. read on ..
Okay good, so in this post, we are going to talk about "Queries" or "LINQ" for the very first time in this Demystifying C# series. I have been asked in comments to talk about the practical application of the new C# 3.0 thingies. I can come up with seemingly lame practical applications, because the real awesome practical application - IS - LINQ (Language Integrated Query).
The practical application of the above 5 C# 3.0 features (which are not the complete set of new things in C# 3.0), can best be understood by understanding Query Expression Translation.
LINQ, as you may already know, looks like TSQL queries, except they are twisted upside down, and written in right inside of C#. You have probably already heard about the benefits, so I won't go into those for now. In here, we are going to talk about Query Expression Translation. You can write queries in LINQ using various keywords such as "from", "where", "select" etc.
Those queries, get translated into plain vanilla C# 3.0 code, and only then type-binding, overload resolution etc. happens. Once the Query has been translated to C#, it is then executed as regular method invocations - where of course you have various C# protections such as a method being missing, data types mismatched so on and so forth.
So, LINQ --> Query --> TranslatedToC#3.0 --> Method Invocation.
So LINQ = Method Invocation? YES - THAT IS WHAT MAKES LINQ, Nothing but Plain vanilla C# 3.0. All those new language constructs, along with Query Expression Translation, make LINQ possible.
Lets understand with the help of an example.
In my last post Demystifying C# 3.0 - Part 5: Object and Collection Initializers, I had a simple example demonstrating Object & Collection Initializers. Basically, we got a List
var theWhiteHouseStaff = new List
It is notable that List
var q = from staff in theWhiteHouseStaff select new {staff.Name} ;
Practical Application: "var q" <-- Anonymous Type (+). An anonymous type that holds an Anonymous Type with one property "staff.Name". Also, "var" lets you create an Implicitly typed local variable (+) . This means, a) You didn't have to declare/write a class structure to hold a type with one property called "Name" of data type string. b) You don't have to maintain that either - you can change the structure of the above query, and "it just works" :)
Now, the above query, can also be written like this -
var q = from staff in theWhiteHouseStaff select new { Name = staff.Name } ;
Practical Application: "new { Name = staff.Name }" <-- Object Initializer (+). The anonymous type, is being initialized by an Object Initializer. The anonymous type doesn't have logic, or a constructor. But it does have public setters on it's properties, so there you go - the Object Initializer can now take advantage of those, and the query is slowly decomposing into plain vanilla C# 3.0.
The above query, further decomposes into the below -
var q = theWhiteHouseStaff.Select(staff => new {staff.Name}) ;
WHOAA !!!, lets look at this query once again, only color coded this time ;-)
var q = theWhiteHouseStaff.Select(staff => new {staff.Name}) ;
(PS: If the RSS Feed eats the color coding, I suggest you come see it on my blog)
Practical Application: The yellow var q, is an Anonymous Type (+) "q", the "var" lets you create an implicitly typed local variable (+). The theWhiteHouseStaff is an IEnumerable
So, the LINQ Query
var q = from staff in theWhiteHouseStaff select new {staff.Name} ;
is *absolutely* the same as the C# 3.0 language construct -
var q = theWhiteHouseStaff.Select(staff => new {staff.Name}) ;
Thus, the (Linq) query expression has been translated (to plain vanilla C# 3.0). This is called as Query Expression Translation, and this is the reason behind C# 3.0 enhancements. :)Cool huh?
