ThinkGeek - Cool Stuff for Geeks and Technophiles

I’ve known about the new dynamic keyword in C# 4 for about a year now but really haven’t thought much about it. It’s suppose to be syntactic sugar for dealing with things like COM interop and objects from other DLR languages. This can be done now by using the existing reflection framework/library, but it can be tedious dealing with method name strings and the chain of method calls needed to get to the method invocation. Variables declared as dynamic bypass static type checking.

I came to the realization today this new keyword might well trigger the downfall of western civilization. Not only can this keyword be used for local variables, but also method parameters and return values. If you have experience working in Corporate America, you know that the there are plenty of developers out there who will abuse this keyword to no end. Can you imagine a ginormous, multi-thousand source file code base littered with dynamic!!! Methods that return dynamic!!! Methods that take dynamic!!! Does this not frighten anybody? I’m so scared. Am I alone? Can we stop this?

Pipelining can be a useful operation when you need to break up code into several steps, perhaps for readability. Typically this is done to avoid a huge mess of nested functions: f(g(h(i(j(k(l(x)))))). Without pipelining you typically need to assign the various steps to local variables. You can get pipelining in C# by extending object with this extension method:

public static TResult Pipe<T, TResult>(this T obj, Func<T, TResult> f)
{
   return f(obj);
}

Example calculating standard deviation with and without pipelining:


List<double> values = new List<double>() { 1, 7, 8, 9, 10, 100, 1000, 1001, 100000 };

double average = values.Average();
double totalVariance = 0;
foreach (double value in values)
{
   totalVariance += Math.Pow(value - average, 2);
}

//OR you could do this:
//totalVariance = values.Aggregate(0.0, (variance, val) => variance + Math.Pow(val - average, 2));

double stdDeviation = Math.Sqrt(totalVariance / values.Count);

//Now with pipe
stdDeviation = values
   .Pipe(v => v.Average())
   .Pipe(avg => values.Aggregate(0.0, (variance, val) => variance + Math.Pow(val - avg, 2)))
   .Pipe(totVariance => Math.Sqrt(totalVariance / values.Count));

Even int gets Pipe():

(2)
   .Pipe(i => Math.Pow(i, 42))
   .Pipe(i42 => Math.Sin(i42));

The benefit, as far as I’m concerned, is avoiding uncessary mutable variables in the function scope (or at least from leaking out to where they don’t need to be).

If you’ve used LINQ and lambdas, I’m sure you’ve come across the occasional function that requires an implementation of IEqualityComparer,or IComparer. You were hoping to write a little Lambda predicate but NOOOOOO, now you have to create a new type and implement an interface. Well no longer. I’m hoping these are the last two classes, in the history of mankind, that inherit from IComparer and IEqualityComparer:

public class Comparer<T> : IComparer<T>
{
   private Func<T, T, int> _compareFn;

   public Comparer(Func<T, T, int> fn)
   {
      _compareFn = fn;
   }

   public int Compare(T x, T y)
   {
      return _compareFn(x, y);
   }

}

public class EqualityComparer<T> : IEqualityComparer<T>
{
   private Func<T, T, bool> _equalsFn;
   private Func<T, int> _getHashCodefn;

   public EqualityComparer(Func<T, T, bool> equalsFn, Func<T, int> getHashCodefn)
   {
      _equalsFn = equalsFn;
      _getHashCodefn = getHashCodefn;
   }

   public bool Equals(T x, T y)
   {
      return _equalsFn(x, y);
   }

   public int GetHashCode(T obj)
   {
      return _getHashCodefn(obj);
   }
}

2 Examples:

List<int> l = new List<int> { 1, 2, 5, 7, 999, 234, 4 };
l.Sort(new Comparer<int>((x, y) => x < y ? -1 : x == y ? 0 : 1));

Dictionary<int, string> d = new Dictionary<int, string>() { { 1, "a" }, { 2, "a" }, { 3, "b" } };

var d2 = d.Distinct(new EqualityComparer<KeyValuePair<int, string>>(
   (kvp1, kvp2) => kvp1.Value == kvp2.Value, kvp => kvp.Value.GetHashCode()));

Are you tired of doing the if(dict.Contains(key))… pattern? Extend Dictionary:

public static R ValueOrSomethingElse<K, V, R>(this Dictionary<K, V> Col, K Key, Func<V, R> Transform, Func<R> SomethingElse)
{
   if (Col.ContainsKey(Key))
      return Transform(Col[Key]);
   else
      return SomethingElse();
}

Example usage:

Dictionary<string, DateTime> BDays = new Dictionary<string, DateTime>();
...
BDays.ValueOrSomethingElse("Mark", d => d.ToString("MM/dd/yy"), () => "Unknown BirthDate");

The second parameter is a lambda for transforming the value if the key is found. The third parameter is a lambda to execute and return if the key is not found. I have the third parameter(something else) as a lambda in case the “something else” is an expensive operation.