Besides the obvious reason of storing any type as an object and storing it in a non-generic collection, what other reasons are there for still using non-generic collections.
As of yet I have found no other purpose, other than backward compatibility with older software, for even keeping these types of collections in the .NET framework.
It seems like it would just create more work, because you’re constantly boxing and un-boxing from type object to it’s original type and vice-versa.
Also you run into the issue of sometimes not remembering what the original datatype of the object was to begin with (eg Double, Float, Decimal). This in fact has to be one of the problems I used to run into when developing in PHP.
Type safety seems like the way to go when developing modern-day applications, as I have created quite a few already and have never been forced to use any of them (non-generic collections).
Or maybe there are other reasons I’m not aware of that make these collections necessary? Obviously there included when trying to pass the certification exam for .NET for a reason. Just not sure why. Could someone please shed light on this subject?
There are very few reasons to do this.
About the only argument I see, on occasion, to use one of the non-generic collections is that there is a potential performance difference in
Hashtablevs.Dictionary<object,object>. This is really due to a difference in implementation, which is described in detail on MSDN here.That being said, I’d still typically use
Dictionary<T,U>– unless there was a very specific reason thatHashtablewas providing some type of advantage, and this advantage could be proven via measurements on a real dataset. Overall, the performance is similar enough that I’ve rarely found issues in real world implementations. In most of my testing,Dictionary<T,U>outperformsHashtable(which, I’m sure, was also Microsoft’s findings, hence they decided to change to a chaining based implementation), but there are some cases whenHashtablecan be faster.