difference between List<object> and List<MyClass>

[Stephan Steiner]

Hi

I seem to have a bit of trouble understanding one bit of how generics work:

In C#, every class automatically derives from object, and inherits a bunch
of properties (i.e. ToString()). Thus,

(MyClass is object) should always evaluate as true.

However, if I have a method with the following signature:

private void myMethod(List<o bjectinput)

And I try to call it

myMethod(new List<MyClass>() )

the compiler complains that it cannot convert from
System.Collecti ons.Generic.Lis t<MyNamespace.M yClassto
System.Collecti ons.Generic.Lis t<object>. And if I try to cast List<MyClass>
to List<objectthat doesn't work either.

Likewise

List<objectmyOb js = new List<object>();
myObjs.AddRange (new List<MyClass>() );

fails with the same error. However, if I I fill up myObjs as follows:

List<objectmyOb js = new List<object>();
List<MyClassmyC lasses = new List<MyClass>() ;
foreach (MyClass c in myClasses)
{
myObjs.Add((obj ect)c);
}

then it works. Even if I leave away the cast to object in the line
myObjs.Add(..) it works (as is to be expected since MyClass is an object.

Since ever class derives from object, why do the the first two examples not
work? Does class inheritance not translate into generics inheritance?

Regards
Stephan

[Marc Gravell]

just because MyClass : object, it does not follow that List<MyClass:
List<object>

What you need is:

private void myMethod<T>(Lis t<Tinput) {}

you can now use
List<MyClassdat a = blah;
myMethod(data); // note the compiler infers T

Marc

[Jon Skeet [C# MVP]]

On Jul 25, 11:08 am, "Stephan Steiner" <stephan.stei.. [e-mail] >
wrote:

<snip>

Since ever class derives from object, why do the the first two examples not
work? Does class inheritance not translate into generics inheritance?

It doesn't translate into type parameter inheritance. Or rather,
generic types aren't covariant in their type parameters, to use the
jargon :)

In short, a List<stringisn' t a List<object>. This actually adds to
type safety - because one of the things you can do with a List<object>
is add *any* object to it, whereas you can't do that with a
List<string(you can only add strings).

Suppose the following were valid:
List<stringstri ngs = new List<string>();
List<objectobje cts = strings;
objects.Add(new object());

The first and third lines are definitely valid - so the only chance
for catching the problem at compile time is for the second line to be
invalid.

Suppose it's valid though - what would you expect to happen? Either it
should blow up at runtime, or the list of strings contains a non-
string. One of the ideas of generics is to push type safety to
compilation time rather than runtime - hence the error.

Jon

[Marc Gravell]

One of the ideas of generics is to push type safety to

compilation time rather than runtime - hence the error.

Just to tie the two posts together, Jon's explanation neatly
covers *why* the "myMethod<T>(Li st<Tinput)" trick works -
inside myMethod, you can now (as an example) add any item
to "input", *as long as* it is castable to T. So:

input.Add(new object());

would fail at compile time, but:

input.Add(new T());

would be fine, given a suitable constructor condition on T:

void myMethod<T>(Lis t<Tinput) where T : new() {}

If you want to allow lists of some class / interface (e.g. to
use properties / methods of such), then the "obvious" (but
wrong) waty to do this is:

myMethod(List<I SomeInterfacein put) {} // not ideal; very restrictire

this is better expressed via a condition:

void myMethod<T>(Lis t<Tinput) where T : ISomeInterface {}

or if you want to allow arrays, collections, etc to be passed in:

void myMethod<T>(ILi st<Tinput) where T : ISomeInterface {}

Marc

[Marcin Hoppe]

In article <11************ **********@22g2 000hsm.googlegr oups.com>,
ma**********@gm ail.com says...

void myMethod<T>(Lis t<Tinput) where T : ISomeInterface {}

or if you want to allow arrays, collections, etc to be passed in:

void myMethod<T>(ILi st<Tinput) where T : ISomeInterface {}

Did you mean IEnumerable<Tin stead of IList<T>? You cannot pass an
array when input parameter is declared as IList<T>. You can pass both
arrays and lists if input was defined as IEnumerable<T>.

--
Marcin Hoppe (marcin.hoppe at gmail.com)

[Marc Gravell]

Did you mean IEnumerable<Tin stead of IList<T>?

I meant IList<T>

You cannot pass an array when input parameter is declared as IList<T>.

Yes you can (working example below). Add() etc will obviously throw an
exception (presumably NotSupported... or InvalidOperatio n...), but
many of the IList<Tfunction s will work fine, such as enumeration,
length query and indexer access - all perfectly type safe.

Marc

using System;
using System.Collecti ons.Generic;
using System.Diagnost ics;

static class Program {
static void Main() {
int[] data = { 1, 3, 5 };
Test(data);
}
static void Test<T>(IList<T list) {
foreach (T item in list) {
Debug.WriteLine (item);
}
}
}

[Marc Gravell]

Not sure if my last post went out, but yes I meant IList<T>, and yes
it works just fine. Add() isn't supported, but you can check the
length, enumerate, use the indexer, etc.

Marc

[Marcin Hoppe]

In article <11************ **********@19g2 000hsx.googlegr oups.com>,
ma**********@gm ail.com says...

Not sure if my last post went out, but yes I meant IList<T>, and yes
it works just fine. Add() isn't supported, but you can check the
length, enumerate, use the indexer, etc.

I wasn't aware of that. MSDN says that both in C# 1.2 and 2.0 a single
dimensional array implements IList (or IList<T>).

Interesting thing is the way method IList.Clear works. It sets all the
elements of the array either to 0, false or null, whichever is
appropriate. The IList<T>.Clear, however, throws an exception.

Thanks for a good point!

--
Marcin Hoppe (marcin.hoppe at gmail.com)

[Marc Gravell]

Interesting thing is the way method IList.Clear works. It sets all the

elements of the array either to 0, false or null, whichever is
appropriate. The IList<T>.Clear, however, throws an exception.

Interesting; I didn't know that...

Personally, I think the exception (IList<T>) is the correct
implementation; if
all you have is a list, you expect Clear() to remove the elements.
Since you
can't remove from an array, it makes sense to throw. I guess the IList
approach was somebody trying to be clever, and ignoring the meaning
from
the contract:

IList.Clear Method ... Removes all items from the IList.
(http://msdn2.microsoft.com/en-us/library/
system.collecti ons.ilist.clear .aspx)

Marc

[Marcin Hoppe]

In article <11************ **********@22g2 000hsm.googlegr oups.com>,
ma**********@gm ail.com says...

Interesting; I didn't know that...

Personally, I think the exception (IList<T>) is the correct
implementation; if
all you have is a list, you expect Clear() to remove the elements.
Since you
can't remove from an array, it makes sense to throw. I guess the IList
approach was somebody trying to be clever, and ignoring the meaning
from
the contract:

IList.Clear Method ... Removes all items from the IList.
(http://msdn2.microsoft.com/en-us/library/
system.collecti ons.ilist.clear .aspx)

Yup. I also think than an exception would be the preferred way to go.

--
Marcin Hoppe (marcin.hoppe at gmail.com)