PowerCollections are happening!

Wow – how did I miss that – Peter has already started blogging about the PowerCollections project!    Peter talks a about how to provide feedback on this project… It is my hope that you take him up on that… I would like to get some good debate going on this work.    


Nice to see that Peter starts off by giving the BCL team a hard time on IComparer and IComparable… I can see this is going to be fun… I have already asked the right folks to respond, but please do add your two cents and\or link some over to the feedback center on MSDN… I love stuff I owning being at the top of the suggestion list – shows people care…. Maybe we can goad Peter into commenting about the K, V naming debate 😉


I also notice that peter chimes in on the base class vs. interface debate .  That is one likely to generate lots of discussion.




Comments (5)

  1. David says:

    Well, that fact that the issue is on top of the suggestions lists is mainly due to the nonsensical way that list is compiled… The issue has an average importance score of 3.7, way lower than the 7 next suggestions. Many people have voted on this issue and found it NOT very pressing (compared to the seven next issues). The correct thing here would be to NOT care too much about this but rather tackle issues with a higher average importance score, right? 🙂

    I already filed this as a problem with the way the compile this list, have a look here if you agree


    Sorry for using this space to get some publicity for this suggestion. But it is a chicken&egg problem: Before they fix this issue new issues will never have a chance to get any votes at all.

  2. Brad Abrams says:

    Very fair point — thanks for raising it David..

  3. Michael Ruck says:

    I also believe that not only are the new IComparable<T> and IComparer<T> broken, but also ICollection<T> and IList<T>. Their definitions were suited mutch better in v1.1/v1.0.

    ICollection<T> isn’t easy to implement on Key/Value containers – What should be T? ICollection<T>.Add(T) doesn’t make sense in this case – Implementing an add for a value without its key?

    IList<T> should be splitted in my opinion: IReadOnlyList<T>, which only provides read-accessors and GetEnumerator()/GetEnumerator<T>() and IList<T>, which additionally provides the Add/Insert/Remove stuff.

    That’s my 0.02€ on the topic. I really hope that Microsoft fixes these minor glitches as they impose quite a number of restrictions and problems on people implementing own collections. I’ve stumbled over both of these issues, while implementing a heap based priority queue.

  4. Our Dictionary<K,V> implements ICollection<KeyValuePair<K,V>>. Some members are implemented explicitly (Add(KeyValuePair<K,V>) for example) and more usable alternatived added publicly (Add(K,V) for example). I think it’s a very reasonable approach for key-value pair containers. You may say that this is not ideal, but keep in mind that no matter how many interfaces we would include in the Framework, they would not be ideal for all scenarios.

Skip to main content