Enum TryParse

I was somewhat surprised to discover that there's no TryParse method for the Enum class in the .NET Framework 2.0. (It's also odd that the docs/compiler keep referring to Enum as a class—and yet the apprpriate where constraint to apply is struct.) So here's a pair of generic methods to support TryParse for Enums:

public static class EnumUtility
{
   public static bool TryParse<T>(string value, out T result)
      where T : struct // error CS0702: Constraint cannot be special class 'System.Enum'
   {
      return TryParse<T>(value, out result, false);
   }

   public static bool TryParse<T>(string value, out T result, bool ignoreCase)
      where T : struct // error CS0702: Constraint cannot be special class 'System.Enum'
   {
      result = default(T);
      try
      {
         result = (T)Enum.Parse(typeof(T), value, ignoreCase);
         return true;
      }
      catch { }

      return false;
   }
}

Enumerate Using

If you ever need to enumerate a collection of IDisposable items, and you find the following code snippet ugly:

foreach (SomeDisposableClass item in collectionOfDisposableItems)
{
   using (item)
   {
      // do stuff
   }
}

You may find the following method useful:

public static IEnumerable<T> EnumerateUsing<T>(IEnumerable<T> disposableItems)
   where T : IDisposable
{
   foreach (T item in disposableItems)
      using (item)
         yield return item;
}

Calling code looks like:

foreach (SomeDisposableClass item in EnumerateUsing(collectionOfDisposableItems))
{
   // do stuff
}

And yes, Dispose() does get called appropriately after you're finished "doing stuff".

Generics and Delegates

I see a surprising number of search hits on this blog for things involving generics, delegates, and collections. So I guess it would be appropriate to write a series of posts on the subject.

This is all pretty rudimentary stuff, so if you're familiar with generics, delegates, and anonymous methods, you may want to just skip this one.

Generics

public static class Assert
{
    public void Throws<T>(/* ... */) where T: Exception {/* ... */}
}

Here we have a method, named as if it were a part of some test framework (say, NUnit). This method takes one type parameter (T), so we can call this method a "generic method".

This method also contains what is called a "type constraint". That bit beginning with where says that any type that stands in for T must derive from (or be) System.Exception. There are other types of… well… type constraints that I don't think I'll cover in this post.

Okay, so what would we need to know to see if a block of code threw a specific exception? Obviously the type of exception we would expect—that's T. But we would also need the block of code, wouldn't we?

Delegates / Anonymous methods

Delegates have been in C# since forever. Event handling in Forms (and Web Forms) uses delegates extensively. So what's the big fuss?

Well, C# 2.0 introduces the very useful concept of anonymous methods. Arbitrary blocks of code that can be passed around and executed at whim.

Wheras before one had to define a method corresponding to a specific delegate's signature, and then construct the delegate (using syntax that still feels a little odd) before being able to pass it around, you can now say:

public delegate void VoidNoArg();

// ...

VoidNoArg myCode = delegate { Console.WriteLine("Hello world!"); };

Neat. But how useful can a void, no argument delegate really be? Very, actually, through the magic of closures. That is, you can actually say:

string greeting = "Hello world!";

VoidNoArg myCode = delegate { Console.WriteLine("Hello world!"); };
VoidNoArg myCode = delegate { Console.WriteLine(greeting); };

myCode();

// output: Hello world!

Note that the anonymous method referrs to a variable outside of its own scope.

Putting it together

public static class Assert
{
    public void Throws<T>(VoidNoArg code) where T: Exception {/* ... */}
}

// ...

int i = Int32.MaxValue;
Assert.Throws<OverflowException>(delegate { checked(i + 1); });

That's just the tip of the iceberg.

Delegates can be generic. Classes can be generic. Generic classes can have methods that take generic delegates. The System.Collections.Generic collections do all of these things. We'll look at this more in a future post…

JSON Serialization Using C# 3.0 Extension Methods

This post on JSON Serialization Using Extension Methods is a nice demonstration of an elegant solution made possible with extension methods. Nice job, Keith.

Collection<T> and explicit interface implementations

Say you're looking at Collection<T> and ReadOnlyCollection<T> in the System.Collections.ObjectModel namespace. You think, “I could use those! In fact, there's a collection I've been meaning to write for awhile:”

class StringCollection : Collection<string>
{
    public StringCollection(params string[] strings) : base(strings) { }

    public string Join(string separator)
    {
        // clearly this is not an efficient solution!
        string[] strings = new string[Items.Count];
        Items.CopyTo(strings, 0);

        return String.Join(separator, strings);
    }
}

class Program
{
    static void Main(string[] args)
    {
        StringCollection strings = new StringCollection("one", "two", "three");
        Console.WriteLine(strings.Join(", "));
    }
}

// Output:
// one, two, three

Perfect! That's exactly what you expected.

Next, you decide to modify your program. You want to add another string:

static void Main(string[] args)
{
    StringCollection strings = new StringCollection("one", "two", "three");
    strings.Add("four");
    Console.WriteLine(strings.Join(", "));
}

Builds fine and… NotSupportedException Collection is read-only!

But wait, we inherited from Collection<T>, not ReadOnlyCollection<T>. What gives?

Well, when we called the base constructor for Collection<T>, we gave it an IList<string>. Okay, so really we gave it an Array of strings, but it was implicitly converted to an IList<string>. That IList was stored as a field within the Collection wrapper (accessible via the protected Items property).

Calling Add calls the explicitly implemented interface member IList.Add on the string[] which (from the docs:) Throws a not supported exception in all cases.

So, how can we modify the StringCollection so that it continues to call the appropriate base constructor, but coerces the string[] to something a bit more useful?

One possibility is to check the IsReadOnly property of the IList before passing it along, like so:

class StringCollection : Collection<string>
{
    public StringCollection() : base() { }
    public StringCollection(params string[] strings) : this((IList<string>) strings) { }
    public StringCollection(IList<string> strings) : base(strings.IsReadOnly ? new List<string>(strings) : strings) { }

    // ...
}

I'm sure there are better ways, though. Any ideas?

Cast Delegate

Following my previous post, Ed went ahead and made a (C# 2.0-usable) Multicast-capable version:

public static T CastDelegate<T>(Delegate source)
    where T : class
{
    if (source == null)
        return null;

    Delegate[] delegates = source.GetInvocationList();
    if (delegates.Length == 1)
        return Delegate.CreateDelegate(typeof(T), delegates[0].Target, delegates[0].Method) as T;

    for (int i = 0; i < delegates.Length; i++)
        delegates[i] = Delegate.CreateDelegate(typeof(T), delegates[i].Target, delegates[i].Method);
 
    return Delegate.Combine(delegates) as T;
}

C# 3.0 and Delegate Conversion

System.Query defines a number of delegate types to help with query expressions. They follow the pattern of:

delegate T Func<T>();
delegate T Func<A0, T>(A0 arg0);
delegate T Func<A0, A1, T>(A0 arg0, A1 arg1);
// etc.

This is all well and good.

Certain methods in System.Query.Sequence take a parameter of Func<T, bool>. An example is Where<T>(this IEnumerable<T> source, Func<T, bool> predicate). Note that the underlying signatures of Func<T, bool> and Predicate<T> match.

Well it turns out that Delegates are kind of funky. For one thing, the Delegate class cannot be used as a generic type constraint. Also, conversion between compatible types of delegates isn't allowed (that is, you can't cast them).

That means that if one has a reference to an existing Predicate<T> one cannot use it as an argument to Where. I'm sure it won't come up much, because it's not often that one has a reference to a delegate without being able to reach the method that the delegate referrs to, but it could happen.

The best way I came up with to convert between two types of compatible delegates:

// CS0702: Constraint cannot be special class 'System.Delegate'
public static T ConvertTo<T>(this Delegate source)
    where T : class //, Delegate
{
    if (source.GetInvocationList().Length > 1)
        throw new ArgumentException("Cannot safely convert MulticastDelegate");

    return Delegate.CreateDelegate(typeof(T), source.Target, source.Method) as T;
}

This isn't great. Something like the following compiles just fine:

Predicate<int> isEven = n => n % 2 == 0;
MailAddress email = isEven.ConvertTo<MailAddress>();

Since Delegate is invalid as a type constraint, there's not really any way around it. I don't think that will ever cause any difficulty, though.

More subtly evil, however, is that conversion between incompatible delegates will appear to work fine at compile time, but result in a runtime error. Oh well. At least now I can do this:

int[] numbers = { 1, 2, 3, 4, 5 };
Predicate<int> isEven = n => n % 2 == 0;
foreach (var n in numbers.Where(isEven.ConvertTo<Func<int, bool>>()))
    Console.WriteLine(n);

// Output:
// 2
// 4

… not that I ever would…

Update: the delegate conversion method has been extended/updated.

Testing internal code

A few upfront assertions:

1. Unit testing is good. For C# code I use NUnit (along with TestDriven.NET).
2. Languages (including C#) have been designed with the internal keyword for a reason. There are legitimate uses for something that's accessible only within one's own assembly.
3. These internal classes/methods are reasonable candidates for unit testing.

So, how do you test internal bits without compiling test code into your deliverable assembly?

It turns out that it's trivial (in the .NET 2.0 Framework): Friend Assemblies (see also).

Say you have two projects: MyCoolAssembly and MyCoolAssembly.UnitTests.

1. In your MyCoolAssembly, open up the Properties/AssemblyInfo.cs.
2. Add [assembly: InternalsVisibleTo("MyCoolAssembly.UnitTests")]

That's it! Now, MyCoolAssembly.UnitTests can access all of the internal classes/methods within MyCoolAssembly.

No conditional compilation symbols. No messy inner classes. Problem solved.

I found out about this useful attribute in CLR via C#, but Jay Bazuzi (whose blog I'd really like to read except that he apparently doesn't post anymore) had already blogged about this very usage back in September of 2004.

Ruby's Enumerable mixin again

On the topic of Ruby's Enumerable mixin, it might be interesting to compare them to C# 2.0's Array/List<T> methods—static for Array, instance for List<T>—and 3.0's Standard Query Operators (System.Query namespace).

In the cases where C# does not support the method, I'd recommend following the link to the ruby docs. There are some rather interesting methods, and a lot can be learned from looking at what other languages support. In fact, some of these methods (each_slice, each_with_index) might be worth implementing as extension methods in C# (a trivial excercise left to the reader).

Ruby Enumerable	C# 2.0 Array/List<T> methods*	C# 3.0 System.Query
all? all? { |obj| block }	bool TrueForAll(Predicate<T> match)	bool All<T>(this IEnumerable<T> source, Func<T, bool> predicate)
any? any? { |obj| block }	bool Exists(Predicate<T> match)	bool Any<T>(this IEnumerable<T> source, Func<T, bool> predicate)
collect { |obj| block } map { |obj| block}	List<TOutput> ConvertAll<TOutput>(Converter<T, TOutput> converter)	IEnumerable<S> Select<T, S>(this IEnumerable<T> source, Func<T, S> selector)
detect(ifnone = nil) { |obj| block } find(ifnone = nil) { |obj| block }	T Find(Predicate<T> match)	T First<T>(this IEnumerable<T> source, Func<T, bool> predicate) T FirstOrDefault<T>(this IEnumerable<T> source, Func<T, bool> predicate)
each_cons(n) {...}
each_slice(n) {...}
each_with_index { |obj, index| block }
to_a entries		T[] ToArray<T>(this IEnumerable<T> source) List<T> ToList<T>(this IEnumerable<T> source)
find_all { |obj| block } select { |obj| block }	List<T> FindAll(Predicate<T> match)	IEnumerable<T> Where(this IEnumerable<T> source, Func<T, bool> predicate)
grep(pattern)	FindAll could certainly specify a predicate that applied a regular expression against each item of the collection.	same for Where.
include?(obj)	bool Contains(T item)
inject(initial) { |memo, obj| block } inject { |memo, obj| block }		U Aggregate<T, U>(this IEnumerable<T> source, U seed, Func<U, T, U> func)
max / min max / min { |a, b| block }		T Max/Min<T>(this IEnumerable<T> source), etc. Note that while there are a few overloads for this method, it looks like the delegates passed in merely provide value extraction. I don't see an overload where you can provide your own IComparer<T> (which is what the second Ruby method does)
partition { |obj| block }
reject { |obj| block } merely returns the collection of the inverse of find_all / select
sort sort { |a, b | block } sort_by { |obj| block }	Sort() Sort(IComparer<T> comparison)	OrderedSequence<T, K> OrderBy/OrderByDescending/ThenBy/ThenByDescending(   this IEnumerable<T> source, Func<T, K> keySelector) OrderedSequence<T> OrderBy/OrderByDescending/ThenBy/ThenByDescending(   this IEnumerable<T> source, Func<T, K> keySelector, IComparer<K> comparer)
to_set
zip(arg, ...) zip(arg, ...) { |arr| block }

Enumerable mixin

I really like Ruby's Enumerable mixin. Methods like each_slice and each_with_index can inspire some really straightforward, elegant solutions.

Porting such a library to C# is trivial, but having to use the 2.0's verbose delegate syntax detracts from the coolness a bit. Using 3.0's lambda expressions on the other hand…

Ruby and C#

Ruby

numbers = [1, 2, 3, 4, 5]
is_even = proc { |n| (n.modulo 2).zero? }

(numbers.map {|n| "#{n} #{is_even[n] ? 'is' : 'is not'} even"}).each {|summary| puts summary}

C# 3.0

int[] numbers = {1, 2, 3, 4, 5};
Predicate<int> isEven = n => n % 2 == 0;

Array.ForEach(numbers, n => Console.WriteLine("{0} {1} even", n, isEven(n) ? "is" : "is not"));

or if you prefer...

Array.ForEach(numbers, n => Console.WriteLine("{0} {1} even", n, isEven(n) ? "is" : "is not"));

numbers.Each(n => Console.WriteLine("{0} {1} even", n, isEven(n) ? "is" : "is not"));


// elsewhere
public static class EnumerableExtensions
{
  public static void Each<T>(this IEnumerable<T> collection, Action<T> action)
  {
    foreach (T item in collection)
      action(item);
  }
}

C# and Ruby

Searching Google for C# Ruby sure yields some interesting articles. I hope to add to the mix in the coming weeks as I play around with the C# 3.0/LINQ May CTP.

Stay tuned…