Are non-generic collections in .NET obsolete?

Question

Put differently:

Is there a good reason to choose a loosely-typed collection over a type-safe one (HashTable vs. Dictionary)? Are they still there only for compatibility?

As far as I understand, generic collections not only are type-safe, but their performance is better.

---

Here's a comprehensive article on the topic: An Extensive Examination of Data Structures Using C# 2.0.

Indicant

Answer 1

The non-generic collections are so obsolete that they've been removed from the CoreCLR used in Silverlight and Live Mesh.

Hebron

What about System.Collections.BitArray? Doesn't really have a generic equivalent. – Materi

@Materi a BitArray is a strongly typed collection of Booleans with special uses, not a loosely typed highly abstract collection of Objects like the OP is talking about – Sebrinasebum

Without non-generic dicts, how would you efficiently and easily store e.g. JSON data, that is full of Dictionary/Hashtable: string-to-(int/string/bool/Dictionary/List)? It seems to me very foolish to discard non-generic Collections, when in the real world most data is - by nature - non-typed, and we need tools like non-generic C's to help us easily pull in, parse, convert, verify, etc...no? – Stephanistephania

Well, it's 10 years later and non-generic Collections are still here, so I'd say Microsoft took the same position. Apropos the accepted answers, non-generics survived longer than Silverlight and Live Mesh! – Secondbest

I don't think this rationale has held up. – Lamellate

Answer 2

There are also issues with COM visibility - COM interop can't be used with generics

Hold

Answer 3

Going forward only generic collections should be used. There is also the benefit of avoiding boxing/unboxing of types in the collection. This is ineffecient, especially when you have a collection of value types that are converted to System.Object when stored on the collection, hence storing the values on the heap instead of the callstack.

Latarsha

Boxing/unboxing only applies to value types. – Generative

And generics can't be used with Com Interop. – Hold

System.Collections.BitArray. Generic equivalent? List<bool> would seem awfully space-inefficient in comparison. – Materi

Answer 4

With regard to using non-generic collections for storing heterogeneous collections of stuff, you can always use List<object> to accomplish the same thing. For this reason alone, I'd say there's almost no reason at all to touch the non-generic collections ever again.

The exception to this would be to maintain compatibility with systems written in other languages, or against previous versions of the .NET framework, but that's a pretty "edgy" case if you ask me.

Seineetmarne

Answer 5

I can tell you that XAML serialization of collections rely on them implementing either IList or IDictionary, so non-generic collections are going to be with us for some time to come.

Sawyers

Answer 6

There might be instances where you need to store objects of unknown types, or objects of multiple different types, but if you do indeed know the type of the objects that you want to store then I cannot see a reason not to use the generic version.

Edit: As commented you can just use List<Object> - doh!

Generative

If you need this functionality, just make the generic of type <Object> to get the old functionality. Always using generics makes your intentions clearer. – Shiller

Answer 7

I wouldn't jump and say that are obsolete or are going to be removed anytime soon. It's true that you should avoid using non-generic collections unless you have a reason not not use a generic version. Thousands of lines of legacy (not so legacy) code is still floating around (and will be for years) that support non-generic collections such as ArrayLists. Since these were the only collections in .NET 1.0 and 1.1, it has been widely used (and abused) throughout the year.

I still occasionally have to interact with an old O/R mapper written in .NET 1.1 that returns IList objects. I have a method that does the conversion to a generic List<>, which is not efficient, but that's the way it is.

And if you need to store different objects in the same array (weird but possible) you will need a non-generic collection. The penalty of Boxing and Unboxing is something you'll have to pay anyway.

Don't be afraid to use them if you feel that you have to.

Sergeant

<blockquote>And if you need to store different objects in the same array (weird but possible) you will need a non-generic collection.</blockquote>Uh, no. creating a ageneric collection specialized to Object works just fine. – Gunlock

Answer 8

Yes, as far as I understand they are only there for compatibility with existing products. You should always use the type safe version (i.e. use System.Collections.Generic over System.Collections).

http://msdn.microsoft.com/en-us/library/ms379564.aspx

Monochromatism

Answer 9

It's almost 2022, and I'm having to write a COM Visible Non-Generic collection class for consumption by a large front end commercially used program written in VB6 - the prime example of such a consumer for non generic collection classes. So I don't see the need for these types of class disappearing any time soon, as there is still a lot of active VB6 code out there.

Meanwhile, use ArrayList and IList to underpin the custom collection class, and check that the individual items are of the type you expect before processing them, e.g.

[ComVisible(true)] public class MyNonGenericCollection : ArrayList, IList { private ArrayList myList = new ArrayList();

...

public int Add(object myItem)
{
    if (!(myItem is MyItemClass))
        throw new ArgumentException(nameof(myItem));

    // code to add to the ArrayList

}

Altheta

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Illene