In prior releases, all the collection classes were sealed, which prevent people from deriving from them. Although I still don't think that there are many good scenarios where it make sense to derive from Set, Bag, BigList, etc., I have unsealed them in the latest drop.

This allows people to derive from them and add new methods; perhaps some specific new algorithm or some such.

However, most methods on these classes remain non-virtual. Why? Basically, because the implementation of these methods is very specific, and it is not possible to override them and change functionality without breaking the core class. Even if the overriding method calls the base, you could find that functionalitybreaks in subtle ways.

For example, suppose you could override Set.Remove, so that you could do something special whenever an item is removed from a set. This override will be called when people remove items from a Set with the Remove method, but there are lots of other methods that remove items from a Set. Some of these ways (like RemoveMany) internally call Remove, others (like IntersectionWith or Clear) do not. You can't predict, and it might even change in future versions of the library.

If you need a specialized kind of collection, the “right” way to do it is to derive from CollectionBase, ListBase, or DictionaryBase, and override the appropriate methods. This can then delegate to a private instance of some collection as needed.