by Michael S. Kaplan, published on 2005/07/31 20:10 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/07/31/445835.aspx
You may be wondering what I am talking about here....
Well, it is about the SortKey class in the .NET Framework, which you get to by calling the GetSortKey method of the CompareInfo class.
The class contains everything you need -- the source string and the binary sort key. So what could be missing?
Well, for starters the flags used to create the instance. The original string is avaiable as is the final result, but there is no way to know how you move between the two. Now I am not saying that this is necessary, but it is a little odd given that an object happens to be there.
In practice, it is hard to know when you would ever need the string -- wouldn't you know what the string is, and thus not need to have another copy of it stored? It seems kind of wateful to me....
Now there is a Compare method that you can use to compare two sort keys, and that is great. But that means if you want to use the functionality to create sort key to build a database index, that you are on your own unless you either (a) serialize the class and thus duplicate the string and the indexing, or (b) take care of the binary comparison yourself. I do not mind (b) and that is easy to do, but wouldn't it better to have a static method to do the work for me? I don't see the serialization here to be a realistic implementation option.
So, these are things that are (in my opinion) wrong with the SortKey class. The real people using it pretty much need to grab out the sort key and then throw it away, since it does not really provide anything else that is needed. I'd be happy if there were just a comparison method available for the byte arrays that make up the sort key data....
referenced by