Generic Collections…

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">As I am sure many of you have heard
we are adding a cool new namespace in Whidbey… System.Collections.Generics… It
contains generic versions of the collections you know and love today. style="mso-spacerun: yes">  List<T>, Dictionary<K, V>,
etc />

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">In addition we are evaluating adding
some new collections to the BCL… As we add those new collections we have to
decide if we add both generic and non generic versions. style="mso-spacerun: yes">    For example, say we added a
LinkedList class to the BCL, should we add both LinkedList and

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Here are the pros and cons as I see

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 

style="mso-bidi-font-weight: normal"> style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-weight: normal">non-generic

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">pro: less surface area to test,
document, explain, etc

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">con: Misses out on all the cool
features of generics (strong typing, performance,

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 

style="mso-bidi-font-weight: normal"> style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-weight: normal">generic

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">pro: less surface area to test,
document, explain, etc

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">con: generics are not in the CLS
until LH (some 3rd party languages don’t have support, but C#, VB.NET
and C++ do support them),

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> style="mso-spacerun: yes">       generics
are still a “new” feature, some folks may not be ready to move to them right

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 

style="mso-bidi-font-weight: normal"> style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-weight: normal">both

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">pro: gives developers

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">con: gives developer choices

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">The con here is that it makes the
entire platform that much more complicated. style="mso-spacerun: yes">  We have to document both, test both,
developers have to know when to use one or the other, etc. style="mso-spacerun: yes"> 

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> style="mso-spacerun: yes"> 

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> style="mso-spacerun: yes">Thoughts\Comments?  BTW, is
LinkedList an interesting thing to add to the BCL?  What would you use it



Comments (75)

  1. Sean says:

    Generic version please.

    While you’re working on the collections namespace, amn I the only one who misses types such as Sets, and SkipLists? Please, someone, get the collections up to/past that of java

  2. Generic only please.

    Perhaps you can have your scriptish languages interpret the generic classes as Foo<System.Object>. Don’t miss this opportunity to make a clean API. It can never be fixed afterward.

  3. Brad,

    How bad will it be to have both? For us it seems like a little more to learn, but more flexibility.


  4. Monty Shaw says:

    You mean that ArrayList isn’t implemented as a linked list? If not I guess I don’t miss LinkedLists. Your question is more valid in light of my ignorance. 🙂

    Seriously, maybe someone needs a list of largish objects where a ‘realloc and copy’ would be too slow. Also, it is easier to reorder a linked list than an array, especially if the object get large.

    Now, what’s a large object?

  5. Frank Hileman says:

    Non-generic collections are not very useful. Especially for something like a linked list. It does not seem like such a lot of extra work for MS, since you just base it on the generic one. Think of all the extra work for everyone else on the planet, when the generic one is missing (typesafe wrappers by the thousands…)

    Here’s a nice link about how bad linked lists are for perf:

  6. milbertus says:

    If you have to choose, I’d rather have the generic version. Every time that I create another subclass of CollectionBase, I realize just how much I can’t wait to have generics, which make all that work pointless.

  7. Ryan says:

    I understand the difficulty of having to test both implementations. Wouldn’t Kenneth’s idea above about Foo<System.Object> for the non-generic implementation would solve a large portion of that problem as long as the performance overhead, if any, wasn’t a problem.

    But if you did implement both what are you worried about in terms of giving the developer choice? In that she’ll mean to use a List of all one type and use a general Object one instead and have to cast it like we all do now? Maybe the compiler can notice that and flash a warning. If you start making generic-only collections people might complain about the imbalance … and doesn’t that make the API ugly from a "purity" standpoint?

  8. Keith Patrick says:

    Why not keep both but have the "original" now be a facade to the commone generics implementation using Object as T? I normally wouldn’t advocate "special case" implementations of a generic in something as general purpose as an API, but Object is a special case of which there is only one.

  9. Jesse Ezell says:

    LinkedList is very cool. I used to use them all the time back in my game programming days.
    As far as the whole generic vs. non-generic thing is concerned, now you see why generics should have been in the 1.0 framework :-). A System.Collections.Generics namespace sounds pretty lame to me (if you insist on using "generic" in the namespace, drop the "s" from the end, because they are "generic" collections not "generics" collections). It makes much more sense to put them in the root of the System.Collections namespace to solve the completity issue. Of course, now we have a little pickle, because there are already all those non-generic ones in there. Can you just replace the types in there with generic versions and provide some backwards compat stuff that instantiates generic classes with the "Object" type when they aren’t used as generics or something? If not,all the old classes should be marked as obselete anyway, because you shouldn’t ever need the old crappy collections and you will incur performance penalties for using them anyway.

  10. SeanH says:

    Ideally, generic equivalents should be included. However, complexity (test, dev) will go through the roof.

    For example, in the case of IList<T>, will this mean that Avalon and WinForms will support databinding using this interface? How about IBindingList? Will it have a generic version?

  11. Anonymous says:

    Every new collection should be a generic one. What’s mostly missing from v1.x is a set (like java.util.Set).

  12. Anonymous says:

    Generic versions only please. If possible, remove the non generic versions that currently exist, and allow old code to run using side by side only.

    Don’t needlessly clutter up the API. Languages without generic support should be supported through the Collection<System.Object> construct someone else suggested.

  13. Keith Patrick says:

    Maybe I just overuse attributes, but I could see building into the compiler the ability to recognize an attribute like [DefaultGenericType(typeof(Object))] such that if a generic is not provided a T that the attribute’s type is used instead. This would prevent having to hardcode typeof(Object) as the default (systematic programmer that I am, I hardcode nothing) and allow flexibility for generic authors.

  14. Keith Patrick says:

    OK, after giving it some thought, I think that is attribute would be a better thing to implement something like that by just having something like System.Type IGeneric.DefaultType, assuming all generics have common ancestry (I confess that I haven’t downloaded the SDK with .Net 1.2 yet)

  15. Ian Ringrose. says:

    I do not wish to always have to write code converting from none generic collections to generic collections, so I would go with generic only. However it may be good if ALL collections implemented the none generic IEnumerable interface, so they can be used in ‘foreach’ loops by people that do not get generics.

    If you HAD to have the new none generic collections, could there be a type def for the generic collections. So that a generic_list<object> is the same as ‘poormans_list’ and can be assigned to each other?

    I would rather not be able to use the new collections in public interfaces that may have to be calllable from any language, rather then have to cope with 2 versions of each collection. The new collections will be most useful as private members anyway.

  16. Generics only please. Don’t bloat the API just for CLS compatibility.

  17. Greg Wilson says:

    Generics only, please. Maintaining both, and explaining to junior programmers when they should use non-generic, and when they should use generic, will be increasingly expensive as time goes on. Would also (strongly) suggest that you get in touch with the BOOST crew (, who are creating interesting extensions to the C++ STL. They have a strong formal peer review process in place, and could probably give you high-quality feedback in a hurry.

  18. Eddie Velasquez says:

    Can you implement the non-generic versions in terms of the generic ones? LinkList == LinkList<Object>? BTW, is there a provision for "typedef"? Using generics with an aliasing feature is kind of complicates things a bit, doesn’t it?

  19. Anonymous says:

    +1 to generic only. Keep API Clean! 🙂

    Side note: could you think of adding interface derived from ICollection<T> with add, remove, count, but without indexed access, like this[], IndexOf, RemoveAt, etc? This is missing thing from my point of view.

  20. James Speer says:

    We must have both…

    The con here is that it makes the entire platform that much more complicated.
    — Not complex, just bigger IMHO.

    We have to document both
    — But if you mix and match classic collections and generics, you then have to document those that are available as generics and those that are not and also document why. I think doing both actually means *less* documentation

    , test both
    — Yep, but we all know that you’ll end up doing both in the long term anyhow;-)

    developers have to know when to use one or the other, etc.
    — Developers have to know how to make that choice anyhow

    HTH, Cheers.

  21. Eric Wilson says:

    LinkedList might be useful. But I would be more excited if some other types of collections like "Heap" or "Balanced Tree" (pick your favorite balancing function) were implemented first. Given the cost of a single cache miss in modern CPU’s, Linked lists look less and less attractive in terms of performance, especially when you have a class like ArrayList that implements the same functionality (admittely with a different memory footprint and access characters).

  22. Marco Russo says:

    Generic only, please!

  23. Dmitriy Zaslavskiy says:

    1. Great idea to add new containers/algrotithms
    2. Add docs to describe asymptotic times. Big O and such.
    3. Generic version only please, a) because it’s the future and b) can’t always produce it by having LinkedList<object>

  24. Mark Levison says:

    Generic only

    In addition to linked lists, please add sets and red-black trees. It would’ve been useful to have both in the past few days.

  25. Maciek Sarnowicz says:

    I vote for generic collections only.
    I also miss several collections, like Set, Queue, PriorityQueue and LinkList. Ideally we would have STL-style set of collections and algortihms that can be mixed and matched as needed.
    Also vote for documenting complexity of algorithms implemented in collections.

  26. Frank Hileman says:

    How about Deque? Better perf than linked list for iterations; suitable where ArrayList is not (incremental increases to very large collecitons). The more time spent on collections the better; they are the backbone of any programming system, right above the CLR. I would like to see the most basic (arraylist, hashtable, maybe deque) optimized with native code right in the CLR, just like arrays.

  27. Generics only please.

    As for "what would you use LinkedLists for?" – they’re much more performant if you need to do many inserts/deletions that are not at the end of the list.

    Like others in this thread, I would like for .NET’s Collections to be brought up to par with the Java Collections Framework, so also add things like Set, TreeMap, etc.

    Also, please change all API methods that currently take a parameter of type ArrayList to accept IList or ICollection instead so it becomes possible to code against the collections interfaces without being bound to a particular implementation.

  28. Corrado Cavalli says:

    I agree with other comments: Generics only!

  29. Just remember that the framework is supposed to be language neutral. As long as languages without support for generics can use the generic versions (default the types to System.Object) I’d say stick to generics only.

  30. Basim Kadhim says:

    Several people on this thread have suggested that languages that do not support generics could simply use an instantiation of a generic collection class with System.Object. This doesn’t work for API’s that include instantiations of generic types, but are not covariant. The issue will have less to do with whether both kinds of collection types (generic and non-generic) are available, but rather what dependencies other parts of the framework will make on those collection classes. Note that for backward compatibility, a majority of the collection classes are likely to exist in both forms anyway.

  31. Aaron F says:

    I’m only interested in the Generic verions. Please consider adding simple search-trees and Sets! While we can of course use a Hashtable as a search tree, it can use up alot of unnecessary space with empty buckets when all you need is a "load-once and search multiple" container. And sets would certainly be a welcome addition.

  32. Aaron F says:

    Oh yeah, PriorityQueue would be nice too.

  33. Keith Patrick says:

    Here’s a question I’d like to pose to folks: at what point is the BCL oversaturated? There are requests for plenty of collections out there, going way beyond what 1.1 has since the BCL is being overhauled due to generics, but at what point do they become so specialized that the class library author determines that it is best to be subclassed by a consumer of the library?

  34. Mads Houmann says:

    What Luke said, especially if arrays are updated to implement IList<T>.
    I saw on Chris Andersons blog that the built in valuetypes will be updated to implement IComparable<T> – great.

  35. Aaron F says:

    Regarding Keith’s post above….

    I don’t have a problem with the BCL supporting various (and numerous)container/collection classes. B-Trees, RB-Trees, LinkedLists, etc. are all well-known and commonly used in many different situations. It is not like the BCL is trying to support a "Person" or "Vehicle" type where the needs of the client could vary wildly. I certainly don’t think that there is much of a chance for "oversaturation" in the Collections namespace.

  36. Don Box says:


    I’m glad to see your readers have such common sense.

    Generic only. No question.

    Once you start using generics, it’s very hard to go back. Sort of like going back to procedural languages after you’ve used an OO language.


  37. Steve Dunn says:

    Is it not the case that internally the link-list is derived from the generic LinkList class (public class LinkList : Collections.Generics.LinkList<Object>) ? If so, just document this (and the possible differences in constructors). Am I missing something? Cheers, Steve

  38. Brian Noyes says:

    Generics by far most important. Maybe some will whine if object based version is not in there, so to keep the most people happy provide both. But if you want to provide the greatest capability while forcing people to do things the right way, go with Generics only.

  39. Corey Haines says:

    Definitely just generics. I was a VB programmer through 4 – 6, and I think the biggest thing holding it back and making it a cluttered language (no offense to anyone) was forcing the compatibility with the previous language (yeah, I know the reasons that happens, but I can still complain about it).
    Everyone here has pretty much hit on the head that we (meaning the development community) are at the beginning of the framework when it is easier to make these changes. After this, we are pretty much stuck with any (hopefully very few) design mistakes that are made.
    I very much like Brian Noyes’ phrasing in the comment above, "if you want to provide the greatest capability while forcing people to do things the right way, go with Generics only." Well said!

  40. Steve says:

    Would really like to see a SkipList<Object>

  41. Eric Friedman says:

    Plenty of people have already said it, but I strongly support generics only. I further believe there should be no System.Collections.Generics namespace. It is my opinion that the lack of generics in versions 1.0 and 1.1 of the .NET Framework was an embarrassing shortcoming. This shortcoming should be fixed as soon as possible without leaving a permanent mark on the Framework API.

    I will try to consider compatibility and usability issues in the following:

    [Compatiblity.] For languages that will not have generics support (and for binaries compiled with pre-generic versions of C#, VB.NET, etc.), attempted use of non-generic List should be transparently interpreted as List<Object> by the CLR. While I am the first to admit the shortcomings of my knowledge of the details of generics support in the forthcoming CLR, I believe this should be possible, or at least could be possible.

    [Usability.] There is nothing more complicated about the semantics of a List<T> than a non-generic List, especially when one considers that the semantics of List<Object> exactly matches those of the non-generic version. Further, if an eased source-level transition is desired, languages such as C#, VB.NET, etc. could support a syntax such as ClassName<> as shorthand for ClassName<Object,Object,…>. Developers would then only need to add empty angle brackets to ‘upgrade’ their code to compile against the new library.

    I believe there are better solutions than providing both generic and non-generic versions of types in the .NET Framework. Since the decisions made before release *will* ‘stick,’ I think the pursuit of an elegant, functional, and usable solution should be given greater consideration than it seems it has been thus far.

    Finally, if what I have suggested is infeasible, please explain to me why. Thanks.

  42. George Mladenov says:

    +1 to generic only. Also, add "typedef" semantics and implement the old collections as
    typedef ArrayList<System.Object> ArrayList;

  43. Keith Hill says:

    +1 for generic only. +1 System.Collections.Generic instead of System.Collections.Generics. With respect to API cruft, it is ashame to already see API cruft build up in just the second major release of the .NET Framework. With WinFX essentially making the Windows API entirely managed it would be worth a lot of time thinking of ways to allow you to fix the API without breaking binary backwards compatibility. Take my current favorite despised update to the API int System.Diagnostics.Process.WorkingSetSize -> long WorkingSetSize64. I would really like to see the API fixed such that it just becomes long WorkingSetSize. As far as source code compatibility goes, we will get compiler errors and we should be able easily enough fix our code. As for runtime binary compatibility, I would think that MS could provide a compat thunk layer (think MessageBoxA/W to underlying implementation of MessageBox) that takes a call to int WorkingSetSize routes it to long WorkingSetSize, takes the result and type casts it to int and then returns it to the original caller. This same technique could be applied to System.Collections by allowing you to convert all the collections over to the generic versions for Whidbey and providing a compat thunk for software written against 1.0 or 1.1. The other benefit of this is that keeps the surface area of the API to just the essentials, not the essentials + the mistakes.

  44. Keith Hill says:

    Sorry, the formatting on the last post was, like, non-existant.

    +1 for generic only.

    +1 System.Collections.Generic instead of System.Collections.Generics.

    With respect to API cruft, it is a shame to already see API cruft build up in just the second major release of the .NET Framework. With WinFX essentially making the Windows API entirely managed, it would be worth a lot of time thinking of ways to allow you to fix the API without breaking binary backwards compatibility.

    Take my current favorite despised update to the API 🙂
    int System.Diagnostics.Process.WorkingSetSize ->
    long System.Diagnostics.Process.WorkingSetSize64.

    I would really like to see this API fixed such that it just returns a long and keeps the name WorkingSetSize. As far as source code compatibility goes, we will get compiler errors that should be easy enough to fix. As for runtime binary compatibility, I would think that Microsoft could provide a compatibility thunking layer (think MessageBoxA/W to underlying implementation of MessageBox) that takes a call to int WorkingSetSize from a 1.x compiled caller and routes it to the long WorkingSetSize on 2.0. It would take the "long" return value and type cast it to an int and then return it to the 1.x caller.

    This same technique could be applied to System.Collections by allowing you to convert all the collections over to the generic versions for Whidbey and providing a compat thunk to service software written against 1.x. The other benefit of this is that it keeps the surface area of the API to just the essentials instead of the essentials + the mistakes.

  45. Mark Hurd says:

    If you do take on the break compatibility suggestions in these comments, make sure you’re ready for the same sort of backlash you got for breaking compatibility between VB6 and VB.NET, right or wrong.

    And those that said you can’t use Microsoft code because they change the language on you will be vindicated…

    Also, have untyped languages been considered much? They might not be the best option for production quality enterprise code, but they are good for scripting, etc.

  46. Non-generic collections are like untyped arrays: nearly useless, error-prone constructs. I’m all for generics-only: if anyone wants an untyped collection, they should either have to say so explicitly (<system.object>), or they should get a compiler warning. Compatibility should be at the CLR level, not the languages.

    On the subject of crowding the BCL, I think *any* inclusion of generally-applicable patterns we all learned in Data Structures 101 should be welcomed with open arms. The whole point of the BCL is to give us the tools to move beyond re-inventing wheels, and the idea of generic trees, sets, etc. is very appealing to me.

    In that vein, I’d also like to suggest some inclusion of some standard algorithms for string searching beyond the one used in String.IndexOf (e.g., Boyer-Moore variants). One dirty secret of programming is that string matching and parsing is still an inordinately large part of our day, and string searching should be tuned to match the application, not just thrown to the whims of RegEx and IndexOf.

    Also, having strongly-typed collections brings the possibility of indexing, searching, and querying for properties within the type specified. I may be getting into DataSet territory here, but I could see plenty of For…Next loops being dropped with, say, an ArrayList with GetFirstByProperty(propertyname, searchvalue) and GetSubsetByProperty() methods.

  47. Mats Lanner says:

    Being a C# bigot, I’m definitely only interested in the generic collections although I can see the the problem with locking out users of other languages and making them, in effect, second-class citizens in the .NET world.

    I would have thought that having the BCL provide a specialized LinkList< System.Object > would solve the problem for languages that don’t support generics, but have to admit that I haven’t read up on all the details of generics yet, so I’m probably missing something that I haven’t thought of yet.

  48. John Morales says:

    + 1 generics only

    they should go in the System.Collections namespace replacing their non-generic parents.

  49. Kyle Cordes says:

    Generics-only makes the most sense to me, in the sense that if you have a LinkedList<T> you can get one for object easily enough (LinkedList<Object>). To make it really slick, though, the generics feature should let you declare like so:

    class LinkedList<type T = Object>

    so that, if the <Whatever> is left off, you get an Object version. This would be nice particularly for old code that didn’t know that LInkedList is a parameterized type – that could would still work without any source change at all.

  50. Michiel van Schaik says:

    Generics-only. I also like the suggestions about adding a "typedef" or aliasing feature.

  51. Rick Byers says:

    +1 for Generic only and to eventually (when Generics are in CLS) mark non-generic as obsolete.

    As for LinkedList vs. ArrayList – this is really an implementation detail I’d rather not be exposed to. If you give users the choice of an array implementation or linked list implementation, do you really think they’ll choose the most efficient one >>50% of the time? To make having two different types of lists useful, there will have to be some good documentation describing the cases in which LinkedList is faster, and I’m guessing its a non-trivial explanation (member size, GC pressure, usage pattern, CPU cache, etc). I think a good guideline is that if it takes a whole page to accurately explain when a user should choose one thing over another, then perhaps the system should be making the choice for the user by default (since <1% of your users are really going to read and understand that information).

    Ideally there would be one implementation which would self-tune, adapting based on my usage pattern. If I know at development time that I’m going to be doing a lot of inserts in the middle, then perhaps I could supply that as a hint.

  52. Neville says:

    Whatever you do, please upgrade the general level of the collection library. You could at least provide trees. This is one of the most glaring deficiencies of .Net vs. Java.

  53. Chuck Hinson says:

    I would have to say that the lack of depth in System.Collections is much more annoying than not having generics.

    And please do include both – I’d like to make my own decisions about whether I use a strongly typed collection or not. I’m a big boy – I know how to make that decision.

    And do give generics their own namespace.

  54. Bruce says:

    I think Generic only is good for advanced developers. For many .net newbies the Non Generic is understood better. So I think we should have both. 😉

  55. I think they should be separate classes (generic/non-generic). If you’re to the point where you’re refactoring your code to use generic types, changing your variable data types from non-generic to generic is the least of your worries. I say keep em separate.

  56. Jeremy says:

    Generics only, except for backwards compatibility. How about System.GenericCollections? Linked list – yes, but it’s almost trivial to write yourself. Also, I’d like collections to be similar in spirit to STL vector and map classes.

    Also, I’d like to be able to write these expressions: myChar.IsWhiteSpace, myString.Trim().Intern(), myString.ToUTF8(), myByteArray.FromUTF8ToString, etc.

  57. piers says:

    Yeah, please flush out the collections classes:
    – LinkedList (single & double)
    – Heaps (binary, fib)
    – SortedMap (I can’t believe you guys didn’t include trees)
    – Sets (sorted, hashed)
    – MultiMap

  58. Val Savvateev says:

    Generics only, please..

  59. Diego Vega says:

    Ok, with some luck this is going to be comment number 59 (I guess that means Brad Abrams won’t ever see it!).

    I though I had something new to say but after reading from the beginning trough Don Box comment, I just have to agree with Kenneth Brubaker.

    In addition, I think I read once that for G<T> to be interpreted as G<System.Object> when no T was supplied there was no need for facades and was completely automatic (even compatible with the CLS). That could mean that you can forget creating the System.Collections.Generics namespace. You just dump the non generic collections and put the new generic collections in place. In the process, you help keeping the API clean and make everybody happy (including legacy code).

    The alternative is to put Generics namespaces everywhere. Please, don’t do it if you can avoid it. Let’s make the framework look as if it was designed with generics in mind from the beginning!

    Obviously I have been reading too much angle brackets, becacause Brad Abrams wouldn’t be asking us for feedback on this if it was that simple. So why isn’t it so simple Brad?

  60. Brad Abrams says:

    Diego is wondered if I read this far down – of course I do. He and others have asked about doing some kind of automatic mapping with the new generics to the old… When we first started thinking about generics in the Framework, even before we RTM’d V1.0, we had a long debate about how to ensure compatibility… and basically found out it was impossible to get 100% compatibility.
    You would also have to make a bunch of restrictions – can other languages subclass generic types and/or override methods? How do they construct instances of generic types? The devil is really in the detail…

  61. Alessandro Forghieri says:

    Both. Or non-generics only.

  62. Miguel de Icaza says:

    My suggestion is to implement both.

    The size of the new collections is likely going to be relatively small compared to the rest of the framework, and you obtain the two pros that you listed.

    Implementation wise, you can implement the non-generic versions in terms of the generic version, so that at least should minimize some of the QA and testing. It does not solve the documentation problem, but that is a minor detail, compared to the fact that .NET is becoming more and more a universal object hub which not only every language will like to get to, but also more trivial scripting systems.


  63. Tim Chase says:


    I am extremely interested in the generics, and the are what I intend to use almost exclusively, at least when it comes to collections. However, backwards compatibility is always an issue, and a particularly important one for something as widely and broadly used as collections.

  64. crazy chess player says:

    Generics only or both
    (U must think of old VB programmers)

  65. Vijay says:

    hmm .. I am a bit late to the discussion but Brad if you are listening then good enough.

    I would love to blankly say that Generics is the way to go and that we should do that without looking back but unfortunately, as far as i know, every single application that stores things using some kind of Caching mechanism or using lists for doing other kinds of operations will break invariably. The whole notion of bringing backward compatibility will be lost if we are going to remove the Collections namespace from the face of Whidbey. I would suggest that there is nothing wrong in providing a non generic Collection implementation as well as a Generic implementation 🙂 It doesn’t hurt the users that way but unfortunately it is extra work to do extra testing and documentation on the team at MS !

    I think, for the Collections that exist already at System.Collections, you could change the current implementation and include a kind of a wrapper over its corresponding Generics counterpart say LinkedList<System.Object> ( Yeah it is dumb 🙁 ) thereby slowly moving each app to be a dependent consumer of Generic Collections alone. Well see if it make sense to you !

  66. Brad Abrams says:

    There are some good comments above on compatibility. I want sure everyone understands that we are not even considering making any breaking changes in the System.Collections namespace. All the collections you know and love today will still be there. ArrayList, Hashtable and friends are unchanged… What we are talking about doing I adding a new collection (LinkedList) in only using generics. So there is no compatibility issues here, much more it is about philosophy of how we grow the framework.

  67. .NET Collections – NEWS !!!

  68. Ken Brubaker says:

    Brad Abrams wimps out and introduces Power Collections, a new community effort to produce a generic collection library.

  69. Thong Nguyen says:

    Please define the IStack, ISet and IQueue interfaces. Having Stack and Queue as concrete classes (as is the case with the BCL 1.0, 1.1 & 2.0) is disgusting from a pure compsci POV.

    I’m not sure I like the fact that the new generic list is called "List" instead of "ArrayList" (ro whatever the implementation is) either. There should generic ArrayList, DoublyLinkedList and SinglyLinkedLists.

    Also, IList should contain methods like Sort and ToArray since they are generic list operations and should not be limited to ArrayList.

    When in doubt, check out java.util.* and stl for inspiration :-).

    I have listed some problems (did this a while ago) with the current collections here:

  70. Thong Nguyen says:

    Forgot to mention that there should be a FilteringEnumerator<T>(Predicate) in the library *somewhere*. It will probably have to an implcit conversion to an IEnumerable<T> so that it can be used with foreach.

Skip to main content