OK, I see what you mean: I.e., despite the linguistic similarities,
ICollection<> is NOT a generic ICollection.
Well, I would like to have a generic ICollection. And surely there's a use
for what they decided to call the ICollection<>, but probably under a
different name? I guess I'll leave it to the far more enlightened architects
to clear this up....
"Greg Young" wrote:
This is not a bug it is by design and it is documented.
From: http://msdn2.microsoft.com/en-US/library/92t2ye13.aspx
"Some collections that limit access to their elements, like the Queue class
and the Stack class, directly implement the ICollection interface."
If you look, the interfaces are also very different from each other in what
they include. The generic one includes methods such as ...
Add, Remove, Clear
Which do not exist on the non-generic ICollection.
I would agree that the terminology is a problem but the class is implemented
as it should be.
Cheers,
Greg Young
MVP - C#
"Dave Booker" <db******@newsgroup.nospam> wrote in message
news:D8**********************************@microsof t.com... Am I missing something here? It looks like the generic Queue<T>
implements
Enumerable<T> and ICollection but not ICollection<T>. (I want to use it
in
an interface that wants an ICollection<T>.)
Is there a reason for this, or is it just an oversight in .NET 2.0?
Is there a computationally easy way to cast/convert a Queue<T> to an
ICollection<T>?