Design .NET – Why SortedDictionary Does Not Implement IReadOnlyDictionary

The OrderedDictionary overloads the indexing operation so that indexing with an integer N will get the item in position N, while indexing with an Object will retrieve the item coresponding to that object. If one were to create an OrderedDictionary<int, string> called myDict, and added items (1,"George") and (0,"Fred") in that order, should myDict[0] return "George" or "Fred"?

Such an issue could have been resolved by imposing a class constraint on the key type. On the other hand, much of the usefulness of generic collections stems from their ability to efficiently work with value types. Imposing a class constraint on the key type would seem a little ugly.

If the class didn't have to be CLS compliant but merely had to work with vb.net, a sensible design might have been to used named indexed properties. Thus, in the example above, myDict.ByKey[0] would have yielded "Fred", and myDict.BySequence[0] would have yielded "George". Unfortunately, languages like C# do not support named indexed properties. While one could have kludged something to allow use of the above syntax even without such properties, the unfortunate decision to wrap the fields of structures like Point and Rectangle means that for myDict.ByKey[0] = "Wally" to work, myDict.ByKey would have to return a new class object. A struct would be more efficient, but compilers would reject what looked like a write to a read-only structure (notwithstanding that the property wouldn't modify the struct returned by ByKey, but instead modify the collection to which it holds a reference).

Personally, I think a dictionary-ish object that was specified as keeping track of the insertion order would be a nice thing to have; I'd also like to have a dictionary-ish object which could easily return the key associated with a particular key (so that, e.g. if one has a case-insensitive dictionary and has added a record with a key of "GEORGE", one could ask the dictionary what key is associated with "George" without having to search through all the KeyValuePair objects returned in an enumeration.

Actually there is a push back in the .NET world against these very things you mentioned. In the first example you gave however, the routing engine is given a convention for mapping the default route. The very fact that the routes are dynamic make it nigh impossible to use a static configuration.

You also mention XAML/WPF, both of which were under development well before generics were introduced into .NET and going back to support generics would have delayed an already very late product (Longhorn/Vista) even further.

There are examples within the ASP.NET MVC framework of using lambda expressions in place of magic strings and the Entity Framework/LINQ takes it even further where the language and framework provides native support for composing SQL queries over a static object graph (instead of constructing magic SQL strings, you get compile time validation of your queries).

For other examples of static configuration see structuremap and other modern dependency injection containers, and other frameworks that need to inspect the object graph at runtime but allow the developer to statically provide hints using lambda expressions.

So the short answer is that historically, .NET did not support static traversal of an object graph until the 3.5 release. Now that we have it, many developers prefer it over magic strings and many have been pushing for even deeper support such as a symbolOf operator that works similar to the typeOf operator.