Skip to content

Addicted to .Net 3.5

Outside of LINQ, i thought that 3.5 was a lot of cool but not vital syntactic sugar. This weekend marks the first time since November that I fired up VS.NET 2k5 to build an app targeting the 2.0 framework and I was amazed how much I'd already come to rely on that sugar. Now this might be seen as an invalidation of my preference of explicit, verbose syntax versus the terse syntax of many scripting languages. I'd like to point out that terseness and expressiveness in sytnax are two separate things. Syntactic sugar that let's me express my action in more concise code that easily conveys the meaning is not the same thing as using a terse vocabulary to keep the typing down and requiring memorization of abbreviated keywords to understand the code. Anyway, here are the parts of 3.5 I've missed more than once this weekend.

Extension Methods on IEnumerable

The plethora of extension methods on all things IEnumerable is largely due to LINQ, but the To* methods have become just a basic part of my vocubulary. Taking the Values of a Dictionary into an Array of the same type now is seems just painfully verbose without the ToArray() method. Compare

FileInfo[] f = new FileInfo[files.Count]; files.Values.CopyTo(f,0); return f;

with

return files.Values.ToArray();

Object/List initializer syntax

Now this I really thought of as frivolous. However, using objects that use DTOs as their initializer/storage, initialization does become rather awkward without loops or long constructors:

FileInfoData[] remoteFileData = new FileInfoData[]
{
  new FileInfoData(),
  new FileInfoData(),
  new FileInfoData()
};
remoteFileData[0].name = "test1.mpg";
remoteFileData[1].name = "test2.mpg";
remoteFileData[2].name = "test10.mpg";
FileInfo[] remoteFiles = new FileInfo[]
{
  new FileInfo(remoteFileData[0]),
  new FileInfo(remoteFileData[1]),
  new FileInfo(remoteFileData[2]),
};
versus

FileInfo[] remoteFiles = new FileInfo[]
{
  new FileInfo(new FileInfoData()
  {
    Name = "test1.mpg"
  }),
  new FileInfo(new FileInfoData()
  {
    Name = "test2.mpg"
  }),
  new FileInfo(new FileInfoData()
  {
    Name = "test10.mpg"
  }),
};

Anonymous delegates are a pain and hard to read

I needed to pass in a delegate to a function as a factory callback. Perfect scenario for a nice concise lambda. But I was in 2.0, so that meant defining a delegate and anonymous delegate syntax resulting ing

public delegate ILocalFileSystemManager LocalCreateDelegate(string localPath, string extension);

public class FileSystemManagerFactory
{
  public FileSystemManagerFactory( LocalCreateDelegate localFactory )
  {
    this.localFactory = localFactory;
  }
}

FileSystemManagerFactory factory = new FileSystemManagerFactory(
  delegate(string localPath, string extension)
  {
    return new MockLocalFileSystemManager(localPath, extension);
  });
instead of

public FileSystemManagerFactory( Func<string,string,ILocalFileSystemManager> localFactory )
{
  this.localFactory = localFactory;
}

FileSystemManagerFactory factory = new FileSystemManagerFactory(
  (localPath, extension)
  =>
  return new MockLocalFileSystemManager(localPath, extension);
  );

Automatic Properties

If there is one feature of C# (well and java as well) that is the most code generated, it's getters and setters. I've never liked how code generation tools created those for me, since i liked having my private members in one place and Properties in another. So i've been typing them out for years. But with C# 3.0, we got automatic properties. The two patterns, read/write properties and read-only properties are oft repeated like this

string readwriteMember;
string readonlyMember;

public string ReadWrite
{
  get { return readwriteMember; }
  set { readwriteMember = value; }
}

public string ReadOnly { get { return readonlyMember; }

Not a ton of code, but certainly takes more time to write than

public string ReadWrite { get; set; }

public string ReadOnly { get; private set; }

Ho hum.. I'm in 2.0, so i'll have to deal, but I certainly hope that 3.5 has a fast pick-up rate on the client (on the server, I can still control my environment).