Missing IOrderedDictionary<>.IndexOf() counterpart in 2.0-beta1

[Markus]

We currently evaluate the migration to 2.0 beta 1 in our codebase. So far we could get almost everything compiling again, but for one function we don’t know what to do.

Is there a counterpart for IOrderedDictionary<>.IndexOf() on the new IDictionary<> interface in 2.0 beta 1?

‌

btw: With the new spring version the binary size of our DLLs were are almost cut in half!

[Stefan Glienke]

May I ask what you are using the result of this method for? In IOrderedDictionary it only made sense in combination with the Items[Index] property but since you are working with a dictionary you directly get the value via the key already and don’t need to go IndexOf(key)->Items[Index]. And to check the occurrence of an item there is the ContainsKey method.

[Markus]

We actually miss the functionality of IOrderedDictionary. We have several situations where IOrderedDictionary suites our use case quite well. With the migration to 2.0 we replaced Items[Index] with IEnumerable<>.ElementAt(Index) and with the hint that the order is preserved due to the hashing algorithm this resembles the IOrderedDictionary. On a downside this approach relies on an implementation detail rather on an API contract.

One use case is:

Imaging you can sort several columns of a TGrid. In the current code we use an IOrderedDictionary. The insertion order is the order in which the user clicked the columns in the GUI. The key is a column key and the value is the sorting direction (asc vs desc). Now we owner draw the TGrid column headers and need to draw the sorting glyph. Here we access the dictionary by key to get the sorting order value but also with IndexOf(columnKey) to get the sorting position (given by the index in the IOrderedDictionary).

I’m very aware of that regular dictionaries don’t have any order. That's why we liked the IOrderedDictionary. Sure we can rewrite the code to use lists. But my point is that IOrderedDictionary was a really handy tool for cases like this and rewriting such code would require state keeping that was done by the IOrderedDictionary.

[Stefan Glienke]

Thank you for the explanation.

I was already kinda assuming you have a use case like this because this is the classic combination of lookup by key plus accessibility via a numeric index that an ordered dictionary or a list with an index (i.e. key) serves.

It is reasonable easy to bring back the IOrderedDictionary interface, add the two missing methods to the implementing class and change all CreateDictionary methods to return IOrderedDictionary. However, with the design of always providing a ReadOnly interface accessible via AsReadOnly, there is a small roadblock to implementing this while also preserving the nice IMT folding for the various implemented interfaces. I will look into how this can be solved without any further breaking changes or drawbacks.

‌

[Stefan Glienke]

I have added the IOrderedDictionary and IOrderedSet interfaces - the CreateDictionary and CreateSet factory methods return those now instead of IDictionary and ISet (but are compatible since the IOrdered... inherit from them).

[Markus]

Thank you Stefan! The experimental migration to 2.0 was much easier with IOrderedDictionary for us!