I encourage you to keep on working on these collections, as the standard collections in .NET are fairly basic.

<br>

<br>One thing I would really like to see is documented performance, i.e. that the documentation of each method include the O() complexity of the operation.

<br>

<br>For example, the XML documentation for Add() on your OrderedSet should say O(log N) so that when I type 'myOrderedSet.Add(' Intellisense will tell me what the cost of the call is.

<br>

<br>I think this convention would help a lot when coding. At least the programmer will be constantly reminded of the cost of each method call.

Human spell checkers like me are an unpopular sort, but you might want to have a second look at the spelling of ‘concatenate’ in both the method name and the documentation.

Sten -- I agree with you, but the documentation of OrderedSet.Add DOES in fact say O(log n) in the remarks section.

Nils -- thanks for catching that!!!

<br>

<br>--Peter

This is confusing me:

<br>

<br>The OrderedSet&lt;ItemType&gt;.View class is used to look at a subset

<br>of the keys and values inside an ordered set.

<br>The OrderedBag&lt;ItemType&gt;.View class is used to look at a subset of the keys and values inside an ordered bag.

<br>

<br>How does Ordered{Set,Bag} have keys and values?  That they both have an inner View class seems odd - it seems to mean that if I had existing usage code of OrderedSet, and wanted to switch to an OrderedBag in order to decide to allow duplicates, then all the views I was using have to update?  Seems like you could have a common ItemsView class for views into item collections and KeyValueView into for views into, well, key-value-based collections :)

<br>

<br>The web listing of BinaryPredicate has the `1 instead of &lt;T&gt;, but that may be someone else's bug, not yours, dunno :)

James: this is a mistake in the documentation. It should say &quot;The OrderedSet&lt;ItemType&gt;.View class is used to look at a subset

<br>of the items inside an ordered set.&quot;

<br>

<br>In practice, you would never directly declare a variable of type View in your program. The vast majority of the time, you use the result once, typically with a foreach or maybe a Clear, or pass it onto another method call. In the few cases where you would hold onto the returned View, you would declare your variable as simply an ICollection&lt;ItemType&gt;.

<br>

<br>This probably could be called out better in the documentation.

Peter:

<br>

<br>That's very good, although I'd like it to be in the &lt;summary&gt; section so it will show up in Intellisense.

<br>

<br>Perhaps as a guideline we could have just 'O(log N)' in the &lt;summary&gt; and then have a little more text in the &lt;remarks&gt;, along the lines of 'The complexity of this operation is O(log N) where N is the number of items in the collection'.

<br>

<br>Sometimes the complexity might be a two-dimensional value 'O(N*M)' and then it would be useful to explain what those parameters refer to in the &lt;remarks&gt;.

<br>

<br>One more thought: would it make sense to name the scaling parameter (i.e. N, M) after the type parameters of the collection? I.e. the complexity would be O(log KeyType) or perhaps just O(log Key). Or even O(log NKeys) and O(NKeys*NItems) so that any type identifier 'XxxType' would be transformed into 'NXxxs'. Just some ideas.

<br>

<br>Anyhow, giving the programmer a quick sense of cost is important, and I'm happy that you have been paying attention to that when documenting.

<br>

I'd probably prefer a notation that referred to the public property that the performance depended on.

<br>

<br>For example:

<br>

<br>O(log(Count))

<br>

<br>Another example would be enumerating keys/values in a Hashtable, which would be:

<br>

<br>O(Capacity)

<br>

<br>That's certainly clearer than M or N.

<br>

<br>As for memory size, maybe use a sizeof() notation somehow.