By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,169 Members | 1,484 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,169 IT Pros & Developers. It's quick & easy.

Does ReadOnlyCollection<T> implement IList<T> ?

P: n/a
Does ReadOnlyCollection<T> really implement IList<T>, like it claims
to do? ...
When I right-click on ReadOnlyCollection and look at its definition,
it says this:

public class ReadOnlyCollection<T>
: IList<T>,ICollection<T>,IEnumerable<T> ...

However, the following code fails its assertion check:

List<string> xs = new List<string>();
ReadOnlyCollection<string> ro = new ReadOnlyCollection<string>(xs);
IList<string> il = ro as IList<string>;
Debug.Assert(il != null);

I don't understand how this is possible. If ReadOnlyCollection<T>
claims to implement IList<T>, then I should be able to cast to it,
shouldn't I?
In a similar vein, the following code fails to compile because, it
claims, ReadOnlyCollection<string> doesnt implement the Insert method.
How is this possible? Insert is part of IList<T>, which
ReadOnlyCollection<T> inherits from, so it should be there!

ro.Insert(0,"hello");

I'm asking these questions because I want to create my own
wrapper-class, similar to how ReadOnlyCollection is a wrapper around
an IList. I need to understand which interfaces I should declare
myself as providing. And so I need to understand why
ReadOnlyCollection declares that it supports the interfaces it does,
and how.

I wonder if ReadOnlyCollection really does implement those interfaces,
but somehow *hides* the Insert method &c.? How is this done in C#? The
documentation specifically says that methds from interfaces must be
public, so I don't know.
--
Lucian
Apr 1 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Lucian Wischik <lu***@wischik.com> wrote:
Does ReadOnlyCollection<T> really implement IList<T>, like it claims
to do? ...
When I right-click on ReadOnlyCollection and look at its definition,
it says this:

public class ReadOnlyCollection<T>
: IList<T>,ICollection<T>,IEnumerable<T> ...

However, the following code fails its assertion check:

List<string> xs = new List<string>();
ReadOnlyCollection<string> ro = new ReadOnlyCollection<string>(xs);
IList<string> il = ro as IList<string>;
Debug.Assert(il != null);
Could you post a short but complete program that demonstrates that?
Here's one which seems to go against it:

using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;

class Test
{
static void Main()
{
List<string> xs = new List<string>();
ReadOnlyCollection<string> ro =
new ReadOnlyCollection<string>(xs);
IList<string> il = ro as IList<string>;
Console.WriteLine (il != null);
}
}

That prints out "True" as expected.
In a similar vein, the following code fails to compile because, it
claims, ReadOnlyCollection<string> doesnt implement the Insert method.
How is this possible? Insert is part of IList<T>, which
ReadOnlyCollection<T> inherits from, so it should be there!

ro.Insert(0,"hello");
No, it shouldn't - ReadOnlyCollection implements IList<T>.Insert
explicitly, so it's only "there" when you're using the
ReadOnlyCollection as an IList<T>. In other words, you can do:

((IList<T>)ro).Insert (0, "hello");
I wonder if ReadOnlyCollection really does implement those interfaces,
but somehow *hides* the Insert method &c.? How is this done in C#? The
documentation specifically says that methds from interfaces must be
public, so I don't know.


Search for "explicit interface implementation". Basically, instead of:

public void MethodName(...);

you do

void InterfaceName.MethodName(...);

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 1 '06 #2

P: n/a
Jon Skeet [C# MVP] <sk***@pobox.com> wrote:
... Search for "explicit interface implementation".
Okay, I understand now. Thanks for the prompt and helpful answer.

Could you post a short but complete program that demonstrates that?


No -- it was a mistake on my part, caused by stopping the debugger AT
the cast rather than after it.

--
Lucian
Apr 1 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.