I'm a big fan of Linq to objects.  I really like the way that you can write much more concise code with it for every day things, not just things that you would think that you normally do with Linq.

One of the things that I almost always do now is use the Linq ForEach instead of the C# foreach statement.  This gives you a nominal amount of code compression.  But the thing I want to write about is using Linq instead of the C# 'for' statement, which I think leads to a lot nicer code. 

I came across this the other day as I actually needed to write a 'for' statement to add a specific amount of nodes to a graph.  Upon writing it, I was like 'gee, there must be a more concise way of doing this', such as where I don't need to do 'for', an initializer, comparison, and incrementation sub-statements.  I mean, I just need to iterate across the integers 0 to 10 and apply a function to each.

The basic model that think of for doing this is provided in Ruby with sequences / ranges.  As an example, here is some ruby that generates the integers 1 to 10 and prints each to the console:



I'm not going to explain ruby in detail, but the (1..10) generates the integers 1 to 10, the '.each' says for each item in the sequence apply the code block that follows.  The code block is essentially a delegage with 'i' as a parameter and which prints 'i' to the console.

So how can this be done in C#?  Well, it requires a couple of steps.  First, System.Linq provides extensions to the Enumerable class, notably the 'Range' method which generates the values between two parameters:



This works fine, but I have an issue with it.  Enumerable.Range (and most things in Linq) returns an IEnumerable.  To iterate across those, you need to use the foreach statement (or a for, or while, that uses the IEnumerable methods), which is not really better than having to use the for loop.  What I'd like is something still more concise.

One thing that can be done is to convert the enumerable to a list using the ToList() Linq extension method:



This works great, but I really don't like having to convert the result of .Range() to a list just so I can apply the .ForEach() method to the result.  Why the Linq extensions don't have a .ForEach() on IEnumerable I don't know; it sure would be handy.  But, we can write our own:



Now that we have this, we can rewrite the code to the following, which is what I've been looking for the whole time:





Perfect, concise, and also using a fluent interface that I really like.

I came across the need today to convert some CSV (excel data on the clipboard) into an array of arrays strings (string[][]); basically a matrix of strings where each matrix element is one of the cells in Excel.

Usually I'd do this through conventional means like nested foreach statements, but I decided I'd like to try this with LINQ.  This is the result I got, which I thought was so very nicely concise:

I've started the development of this library.  It's been an interesting experience using the existing Amazon EC2 C# library as a base for this library.  All I've got to say about that library is it really is coded weird;  I'm not going to say its coded badly, lets just leave it at weird.  Lets just say it really appears to be coded by a non .net person.

If you remember from an earlier post, I have a few requirements for this library:

• It should compile and run under both WPF and Silverlight with the same code base
  
• It should make asynchronous calls the norm (since that is the model for Silverlight)
  
• It should use the WebClient class, the norm for Silverlight

Yes, I'm kind of coding to the least common denominator of Silverlight (as versus to WPF), but it is a better model in my mind anyway.

One of the first issues I had was in determining how to issue REST requests for EC2 using the WebClient class.  Believe it or not, I really did not find a lot of info on this while googling around.  In the end, it turned out to be pretty easy.  The code to do this is exemplified in this picture:


In short, this method takes a dictionary of key value pairs which are mapped to REST parameters.  Each caller of this method (like the AttachVolume method) will set its parameters (at a minimum the Action key).  It then adds in the required parameters in the call (access keys, signatures, ...), most of which are passed in on the constructor of this object and others calculated on the fly.

The WebClient object is then created, and the proxy added if in use, and then two headers that are required.  A callback is setup for handling the async response, and then the data is passed up with a POST method using the UploadDataAsync method.  I happen to pass a custom object as the UserData that encapsulates a callback passed from the calling method, and that can be seen in the explanations to come as well as by examining the async handler.

That's pretty much it to send the REST command to EC2.  Now lets see how to construct a command that uses this technique.

I've been building this out with an immediate need which requires me to be able to attach and detach volumes from an EC2 instance, so I have focused on the Attach-Volume, Detach-Volume, as well as the Describe-Volumes commands (the last is needed to track the attach/detach status).  As an example, lets look at the code to detach a volume:

I'm brushing up on my LInQ today for a few reasons.  One is that its been a while since I used it because my current client isn't that far ahead and I need a refresher.  Second is that I want to build up some interview questions.  Third is I need to update an intro to LInQ presentation I have previously built. 

The true reason though is that I want to write out a few of my opinions on the technology, and explain a few things from the perspective of how I see them.  One of those things is how the new C# 3.0 language extensions facilitate LInQ.  I think sometimes that people think that these features were added to C# as independent items that developers have requested.  I don't really see it that way, as I think that although they are useful (and very useful at that) by themselves, that they are only added to the language to allow LInQ.  If they were not added, the expressivness of LInQ statements would be greatly reduced, and as a matter of fact it would not event be possible.

The following are the new C# 3.0 features and how I see them related to LInQ:

• Local Type Inference

Required for handling query / selection results.  Often (mostly) the type of this object may not be of a type that is defined in the system at compile time.  An example is a projection of just a few properties from a result object (via select) instead of the whole object.  In this case, the compiler / run-time will create an anonymous type whose type (likely a class with with properties) that can be inferred through the a var keyword.  This is tightly intertwined with anonymous types.

• Anonymous Types

Required to allow the creation of results from where and select queries.

• Lambda Expressions

Required to efficiently code expressions for the selection and projection steps of a query.  With out them, you would need to declare a delegate (either explicitly or anonymously) which would add to the coding overhead.

• Extension Methods

Needed to extend existing classes to have new LInQ methods such as .Where, .OrderBy, .Select, ...

• Object Initializers

Allow the compiler / run-time to efficiently initialize properties of anonymous classes.  Without them a constructor would need to be injected into the anonymous class.

• Query Expressions

Provide a syntax similar to SQL, which is used to manipulate data, but provides a short-hand for the coder that the compiler converts into specific classes and method in LInQ.