Understood. But anyway users will develop generic collections for their specific cases and those collections will implement generic interfaces. To adopt to generics, let me rephrase the question: "Is there any chance we will have more collection interfaces besides ICollection<T>, IList<T> and IDictionary<T>?" To me, indexed access methods in IList<T> seems like misnamed interface. I understand that it might be a breaking change to remove indexed access from IList and invent something like IArrayList, but since generic interfaces are not yet used, it may be good idea to fix the naming problem.

Thanks for the response. A different hashtable class could be created by anyone. But the FNV is not a new data structure, as much as a new way of computing hash codes. So to use these more modern types of tables, you need different GetHashCode algorithms, in many cases. I asked because the more GetHashCode functions that are written, the more we are locked into the old type of hash table. And the newer algorithms, such as FNV, are supposed to be much more efficient in distribution (which means faster and smaller tables). Many OS hashtables are much faster thanks to FNV.

I am very happy to see this being addressed!

I have had the same problem, Ilya. Sounds like you want a logical organization a la STL. A good idea.

While you guys are considering this, could I ask for some enhanced overloads on the BitConverter's ToString method? Essentially, I'd like to be able to specify the separator used on the string that is created, much like Guid a bunch of format codes for different Guid string formats. The immediate application of this for me is in building LDAP binding string and search filters from binary data. Often I have to create a binding string like <SID=xxxx> where xxxx is the octet string format of the binary SID (little endian for AD....) with NO separator characters. Other times I need to build an LDAP search filter which requires a prefix of \ in front of each hex pair. It seems like this would be trivially easy to add and would probably help out more people than just the LDAP developers out there. Maybe even some format string that would allow you to specify the case of the hex digits would be possible? Thanks in advance for the consideration!

Antoher fair suggestion, and we'll keep a track on that one also: thanks Joe!

In answer to your second question Ilya, It's not likely in the near future. We will ALWAYS consider additional interfaces and designs, and in fact, we're actively exploring the most reasonable collections and ideas all the time. But right now, parity between generics and collections is taking all our efforts, so that will remain the focus.

Thanks Frank!

FNV isnt the only possible string hash function, and, in fact, FNV produces bad bit distributions amongst the higher bits. See "Performance in Practice of String Hashing Functions" by M.V. Ramakrishna and Justin Zobel for a thoughrogh review of string hashing functions. http://citeseer.nj.nec.com/ramakrishna97performance.html See also http://www.burtleburtle.net/bob/hash/evahash.html by Bob jenkins for a thoughrogh review of hash testing approaches.

Sorry for accidental posting on question form, I decided to ask here instead but it submitted for some reason, please discard. In MSDN it is stated that a Hashtable can support one writer and multiple readers concurrently. On the other topic it is written that "To support one or more writers, all operations on the Hashtable must be done through the wrapper returned by the Synchronized method.". Which is true? If first, aren't there performance issues for single-threaded application, or how do you achieve one-writer-many-readers without copying data locally? If second, there is a bug in SyncHashtable not locking indexer getter...

FYI - we have thought about changing the hash function on String, and we might do that sometime depending on some performance testing. It looks like we already have tweaked it a little bit since V1.1. We do hope that no one depends on the current behavior of GetHashCode, as we'll probably change it. Just ensure that you don't persist hash functions to disk or try to reverse engineer our hash function - you'll be broken later if you do. BTW, we have changed the behavior of Object::GetHashCode and ValueType::GetHashCode for performance reasons - they still obey the contract that they must obey, but if you are somehow counting on an object to give you the same value between different versions of the CLR, you have a problem. (Note that Hashtable implements an OnDeserializationCallback which calls GetHashCode on every key again, so this isn't a problem for serialized Hashtable instances.) The upshot is we reserve the right to reimplement GetHashCode on every object differently in every build of the CLR.

damien: yes, I saw those papers. The Zobel one seems a little old, testing perf on a sparc 20? I am not saying FNV is the best, but if you look around, you will see where it has been used and made a big difference. The main point is that more support is needed from the BCL because if people write their own GetHashCode functions they may be optimizing to a particular type of data structure. Also regardless of your favorite hash algorithm/structure the mod prime one is dated.

Yes but if you want to reuse a thread to do different kind of job (à la ThreadPool) it can be great to be able to modify its name.

Could be a break change. I'm not sure it's can be done.

I would like to add that the ability to make compound files would be very useful as well. I have need of them in a project and I'm considering using zip files instead.. but a true managed compound file would be very very cool. thanks.