On the recent Delphi 2009 roadshow in Australia, I had a few people ask me about the new TDictionary<TKey, TValue> container in Generics.Collections. If you haven’t played with it yet,  Roland Beenhakker has a nice write up on using it, but most of the questions I was getting were not about how to use it, but about what it’s for.

The way I try and explain it is by stepping back and looking at collections that people already are used to. Leaving implementation details aside, a lot of the Delphi collections store values and let you retrieve those values using a key.

For example, a TStringList lets you store strings indexed by an integer value. So in this case, the value would be a string and the key would be an integer. A TList lets you store pointers and retrieve them using an integer. Again, the key is an Integer, the value is a pointer.

The next step is to think about TList<T>. It’s not that different, the key is still an integer, just the value can be parameterised using generics.

If you’re ok with that, then a TDictionary<TKey, TValue> is pretty easy to understand. It’s a generic container that lets you parameterise not only the value, but the key also. So, to get somewhat similar behaviour to a TStringList, you could use a TDictionary<integer, string>. Now, of course the implementation details of how TDictionary would store those strings is wildly different to a TStringList, but in terms of understanding it, I think it helps.

Equally, a TList<T> might be replaced in broad terms with a TDictionary<Integer, T>, with T being whatever type you like.

The really cool thing though, is that the key part does not have to be an Integer. You could instead of TDictionary<Integer, String> do something like TDictionary<string, string>, so a string could be retrieved by using another string as a key. If you’re trying to think of an example of that, what about the TDictionary’s real world namesake, a dictionary. The key string would be the word, the definition would be the Value.

Further, it could be TDictionary<TGuid, TState>, where you might be using a GUID as a sessionID to retrieve an object that stores your session state in some sort of distributed system.

An interesting take on this is to use a TDictionary to store code in the form of anonymous methods. Anonymous methods are defined as types, so no reason they can’t be stored in a collection just like data. I find this really interesting. If you’re a fan of using table-driven development to replace convoluted if..then…else or case statements, this might spark some ideas. In fact in my next blog post I’ll show an example of a generic Factory implementation that uses a TDictionary internally to store anonymous factory methods.

Anyway, there is a lot more to know about TDictionary’s, such as hashing functions, comparers, etc, but hopefully this has at least given you a high-level understanding of where you might look at using them.