IList and IList<>

  • Thread starter Thread starter nicolas.rolland
  • Start date Start date
N

nicolas.rolland

Would anyone know the reson why IList<T> does not implements IList ??


This results in strange behaviours, like

typeof(IList).IsAssignableFrom(typeof(List<string>)) --> true
typeof(IList).IsAssignableFrom(typeof(IList<string>)) --> false
 
<[email protected]> a écrit dans le message de (e-mail address removed)...

| Would anyone know the reson why IList<T> does not implements IList ??

Because, if it did, you would end up with an interface that had two Item,
two Add, two Contains, etc. properties and methods.

IList deals with all list operations as System.Object, IList<T> deals with
all the same operations as strictly typed to the type of T.

Interface inheritance is not always as appropriate as class inheritance.

Joanna
 
Joanna Carter said:
<[email protected]> a écrit dans le message de
(e-mail address removed)...

| Would anyone know the reson why IList<T> does not implements IList ??

Because, if it did, you would end up with an interface that had two Item,
two Add, two Contains, etc. properties and methods.
Click to expand...

Just as IEnumerator<T> does... I suspect there's a good reason for the
inconsistency there, but it's present nonetheless :(
IList deals with all list operations as System.Object, IList<T> deals with
all the same operations as strictly typed to the type of T.

Interface inheritance is not always as appropriate as class inheritance.
Click to expand...

And class inheritance isn't always used appropriately to start with ;)
 
"Jon Skeet [C# MVP]" <[email protected]> a écrit dans le message de (e-mail address removed)...

| Just as IEnumerator<T> does... I suspect there's a good reason for the
| inconsistency there, but it's present nonetheless :(

Now, I do find it useful to have both versions there :-)

| And class inheritance isn't always used appropriately to start with ;)

Hmmm, didn't you know the world can be modelled using nothing other than
inheritance ? <gd&r>

Joanna
 
Interface inheritance is not always as appropriate as class inheritance.
Click to expand...

The way I see interface is that it is a synonym for a "contract"

That by the way, is why you can't have a public modifier keyword when
explicitly implementing an interface. because you are not supposed to
access directly form an object a interface member. aka you have to read

toto.interfacemember()
as a shortcut for
(toto as interface).interfacemember()


So, following that notion of contract, i see no reason why a IList<T>
contract does not fullfill a IList contract.

I agree that would be too much code though so it might not be
practically appropriate
I guess this makes a case for a form of dynamic interface.
 
<[email protected]> a écrit dans le message de (e-mail address removed)...

| The way I see interface is that it is a synonym for a "contract"

Agreed

| So, following that notion of contract, i see no reason why a IList<T>
| contract does not fullfill a IList contract.

MY thought is that the hierarchies, non-generic and generic are split
differently and could not be reconciled because it would break backwards
compatibility.

public interface ICollection : IEnumerable
{
int Count { get; }
bool IsSynchronized { get; }
object SyncRoot { get; }
void CopyTo(Array array, int index);
}


public interface IList : ICollection, IEnumerable
{
bool IsFixedSize { get; }
bool IsReadOnly { get; }
object this[int index] { get; set; }
int Add(object value);
void Clear();
bool Contains(object value);
int IndexOf(object value);
void Insert(int index, object value);
void Remove(object value);
void RemoveAt(int index);
}

public interface ICollection<T> : IEnumerable<T>, IEnumerable
{
int Count { get; }
bool IsReadOnly { get; }
void Add(T item);
void Clear();
bool Contains(T item);
void CopyTo(T[] array, int arrayIndex);
bool Remove(T item);
}

public interface IList<T> : ICollection<T>, IEnumerable<T>, IEnumerable
{
T this[int index] { get; set; }
int IndexOf(T item);
void Insert(int index, T item);
void RemoveAt(int index);
}

As you can see, the members of IList<T> are not just typesafe equivalents of
IList, the members are split differently between ICollection and IList.

The question would be raised, which is the bettter split of functionality ?

One other point : why do the List interfaces inherit from IEnumerable again,
when inheriting from ICollection would already give this functionality.

Joanna
 
So, following that notion of contract, i see no reason why a IList<T>
contract does not fullfill a IList contract.
Click to expand...

IList has the Add(object) method. Unless the object happens to be of the
right type, that would have to fail - basically you lose compile-time
type safety, which is meant to be the point of generics.
 
Back
Top