Why List<T> does support IsReadOnly.


J

jehugaleahsa

Hello:

I feel like I am missing something here. List<T> implements IList<T>
which in turn implements ICollection<T>.

Way down, there is a property in the interface called bool IsReadOnly.
However, when you look at the List<T> class, it doesn't support this
method. What is going on here? Is there a way to hide interface
members in derived classes? or is this something language feature I'm
not aware of.

Thanks,
Travis
 
Ad

Advertisements

J

Jon Skeet [C# MVP]

I feel like I am missing something here. List<T> implements IList<T>
which in turn implements ICollection<T>.

Way down, there is a property in the interface called bool IsReadOnly.
However, when you look at the List<T> class, it doesn't support this
method. What is going on here? Is there a way to hide interface
members in derived classes? or is this something language feature I'm
not aware of.

Explicit interface implementation. You can still call IsReadOnly, but
only if you go via the interface, e.g.

List<string> x = new List<string>();

IList<string> y = x;
Console.WriteLine (y.IsReadOnly);
 
J

jehugaleahsa

Explicit interface implementation. You can still call IsReadOnly, but
only if you go via the interface, e.g.

List<string> x = new List<string>();

IList<string> y = x;
Console.WriteLine (y.IsReadOnly);

Do you mean you can do an explicit interface:

bool ICollection<T>.IsReadOnly
{
get { return true; }
}

See, I thought that implicit interfaces simply allowed developers to
create specialized methods, etc. It seems a little counter-intuitive
to me that you would hide a member of your interface. I can see when
it would be nice, but I don't think I like it.

Thanks,
Travis
 
J

Jon Skeet [C# MVP]

Do you mean you can do an explicit interface:

Well, explicit interface implementation.
bool ICollection<T>.IsReadOnly
{
get { return true; }
}

See, I thought that implicit interfaces simply allowed developers to
create specialized methods, etc. It seems a little counter-intuitive
to me that you would hide a member of your interface. I can see when
it would be nice, but I don't think I like it.

It's not generally a great idea, no. But occasionally it can be useful,
particularly when you want to declare another method with the same
signature apart from the return type. Implementing IEnumerable<T> would
be impossible without this :)
 
Ad

Advertisements

M

Marc Gravell

It seems a little counter-intuitive to me that you would hide a member of your interface.

That's because it only makes sense when you consider things as the
more abstract ICollection<T>; if you have a List<T>, then you already
*know* that it is editable - so why bother having it appear in
intellisense etc? If you only know that you have an ICollection<T>,
then it is reasonable to ask if that *specific* implementation is
editable. For example, an array implements ICollection<T>, but you
obviously can't Add() things to an array - hence it returns false.

This type of use is really intended for use-cases such as binding
grids to objects, with optional "new row" support - it isn't generally
intended for use by consumers of more specific containers.

Marc
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top