The Ancient Art of Programming

I started 2005 with a bang: my new job at JTeam. JTeam was started by two former coworkers of mine at SmartHaven: Alef Arendsen and Joost van de Wijgerd. To quote the website:

JTeam is a small innovative, Amsterdam-based software company, dedicated to satisfying customers by delivering high-quality software based on open standards, proven technology and a team of experts that are always focusing on the best solution possible. The best solution possible does not always mean it’s going to costs tons or takes ages. The best solution is the one that makes everybody happy.

JTeam has completed a number of impressive Java (J2EE) projects, including the middle-ware of the popular search engine Ilse. It has also started to investigate the .NET framework, and that is where I come in the picture. Though I have a Java background, the last serious Java application I created was almost three years ago.

So far, it has been very interesting. For the past three days, I’ve been mainly looking into the lightweight (EJB-less) Spring Framework. I am looking forward to playing it’s .NET counterpart Spring.NET, though I wonder whether there really is a need for such a framework in .NET.

I consider .NET class SortKey as one ugliest kludges of the entire .NET framework, especially if you compare it with the Java CollationKey class. Why?

First, there is the static Compare method, but the SortKey does not implement IComparable, nor IComparer. This makes it pretty hard to store them in sortable collections as the ArrayList.

Second, the Equals and GetHashCode of SortKey operate on both the byte array and the original string. Imagine a scenario where you have a set of localized strings, and you want to check whether the set contains a certain word in various spellings. So the list might contain the German “weiß”, which means it also contains “weiss”.

One would think that the fastest ways to implement this using .NET is to create a Hashtable with SortKeys as keys, and to check whether the table contains a certain key. However, since the Equals and GetHashCode also operate on the original string, it will not work. The byte arrays might be equal for weiß and weiss, but the original strings are not.

Both of these issues can be resolved (the first by writing a IComparer adapter which uses SortKey.Compare; the second by a custom IHashCodeProvider which only relies on the byte array), but kludges they remain.