Why doesn't ICollection have a Contains method?

[andrew.miadowicz]

It's funny that I've only now run into this question, after a few years
of using C#, but I find it intriguiging all the same. All the more so,
that the generic version of ICollection in .Net Framework 2.0 has this
method.

It seems to me that the question whether a collection has some element
should be answerable by any collection, not just IList or IDictionary.
An obvious implementation must exist, since every ICollection inherits
IEnumerable.

I ran into the problem, where I wanted to use a collection as general
as possible (i.e. not limiting the user to go down the IList or
IDictionary path), but I need to tell whether it contains a certain
object. I can implement it myself, but wouldn't it be easier if
ICollection simply provided a method.

Does anyone have any comments? Are there any plans to add this method
in .Net Framework 2.0?

Thanks,

Andrew

 

[Alejandro Lapeyre]

All its says is that you can travel the items (as IEnumerable),
and as a great concession it also gives you the Count,
and take a snapshot of its elements into an array.
It is therefore targeted to lists of items that can not be quickly found by
item.
Although there is an obvious implementation, that obvious implementation is
slow.
Requiring to find an item could be a significant constraint in
many cases, so as to avoid implementing it.

It also lets you get a synchronized collection.

That all seems me an enough forward step from IEnumerable.

The next step is IList.

best regards,
Alejandro Lapeyre

 

[andrew.miadowicz]

You may have misunderstood what I meant. I wasn't trying to say that
ICollection does not offer functionality beyond IEnumerable. Rather, I
believe that it should have a Contains method.

What you say about its implementation potentially being slow is true,
but it is also true for a generic IList interface, and yet it is
available there. I think that Contains is generic enough to be
available at the ICollection level instead of separately at the IList
and IDictionary levels, which imply a certain implementation. Say, I
have a function that takes a collection parameter. I don't care if it
is a list or dictionary, but I need to know if it contains a certain
item. In other words the lack of the Contains method forces me to user
either IList or IDictionary, where I could have used a more generic
ICollection, unless of course I implement the obvious (and slow) linear
search using IEnumerable myself.

Generally, I don't care how the Contains is implemented by the class
that implements ICollection. I trust that it's implemented in the best
way possible, and in a way much better than what I can come up with not
knowing anything specific about the given colleciton. Suppose that the
ICollection passed to my method is in fact a Hashtable. If I had
access to Contains via ICollection I could get the answer I need very
efficiently. However, if I have to use IEnumerable to implement my own
linear search, my version of Contains is going to be very slow.

Therefore, I believe Contains belongs in ICollection. I think that's
what motivated its inclusion in the IGenericCollection. I just wonder
why it doesn't show in ICollection even for .Net Framework 2.0.

Andrew

 

[cody]

They can't add a new method to a interface since it would break all code
that uses this interface.