Sunday, July 02, 2006

The Way Frameworks Go

While converting NxBRE to .NET 2.0, I came to realize that the SDK has been super sized.

Being a daytime Java geek and an open source developer on .NET, I can say I have a fairly good grasp of the two frameworks. When I started to work on .NET, I really appreciated the compactness and the clarity of its SDK. Informative namespace monikers and well-thought APIs were two features a guy coming from Java could appreciate.

Now the whole stuff is getting really fat, really Java-ish to speak frankly. But this is not the super sizing that I find disturbing.

The introduction of generics has triggered some really strange forks in the SDK. Take a look at the System.Collections namespace and you will notice that it has spawned a generic version of itself under System.Collections.Generic.

I would really appreciate if some .NET guru could explain why such a thing has happened? How come the existing collections have not been made generic? This has been done in Java, why not in .NET?

Now we end-up with two IDictionary interfaces, which can be a pain to handle in the same class. This can happen because you can not and do not want to use generics everywhere, especially if you look for performances with millions of entries collections.

To add to the confusion, the common implementation of IDictionary that was Hashtable has now a generic counterpart named Dictionary. Who said consistency was bad? I leave to the reader to appreciate the definition of Dictionary:
public class Dictionary<TKey,TValue> : IDictionary<TKey,TValue>, ICollection<KeyValuePair<TKey,TValue>>, IEnumerable<KeyValuePair<TKey,TValue>>, IDictionary, ICollection, IEnumerable, ISerializable, IDeserializationCallback

Truly delightful. I wonder how many pearls like this now hide in the SDK...

I thought .NET was a Java copycat but without its flaws. Not anymore. That is the way frameworks go.

PS for the Ruby guys: beware!