Why List<T> does support IsReadOnly.

[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

 

[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);

 

[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

 

[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

 

[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