Question about Generics

[hammad.awan_nospam]

Hello,

I'm wondering if it's possible to do the following with Generics:

Let's say I have a generic member variable as part of a generic class
like this:

List<DLinqQuery <TDataContext >> _queries;

where DLinqQuery is a generic class that takes a type parameter
TDataContext.

This member variable is part of a generic class called
DLinqDataSource <TDataContext > and is exposed as a public property of
the specified type.

It is assumed that all TDataContext types will be derived from the
concrete class DataContext.

Now, let's say I derive a class from DataContext called MyDataContext.

I the create two concrete classes like this:

public class MyDataQuery : DLinqQuery<MyDa taContext>{}
public class MyDataSource : DLinqDataSource <MyDataContext> {}

I want to be able to override the property in the MyDataSource class to
return a List<MyDataQuer y> instead of the generic
List<DLinqQuery <TDataContext >> which would become
List<DLinqQuery <MyDataContex t> in an instantiation of MyDataSource.

Unfortunately, casting the base property value (which is a
List<DLinqQuery <MyDataContext> > to the type List<MyDataQuer y> just
doesn't work, but from a functional perspective it seems like that it
would.

Any ideas on whether this can be done?

[Nicholas Paldino [.NET/C# MVP]]

The reason you can not do this is because generic types are not
covariant (I believe that is the term). This means that if you have a type
Dog which derives from Animal, and a List<Dog>, you can not cast it to a
List<Animal>.

The reason for this is that when you have a class, Cat which derives
from Animal, and you have the new List<Animal> (cast from List<Dog>), that
list wouldn't know what to do with the Cat when it is added.

The workaround here is to define your classes like so:

public class MyDataQuery : DLinqQuery<MyDa taContext>{}

public class MyDataSource<T> : DLinqDataSource <T>{}

Then, when you declare your MyDataSource, you would do this:

MyDataSource<My DataQuery> ds = new MyDataSource<My DataQuery>();

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m
"ha************ ****@gmail.com" <ha*********@gm ail.com> wrote in message
news:11******** **************@ y41g2000cwy.goo glegroups.com.. .

Hello,

I'm wondering if it's possible to do the following with Generics:

Let's say I have a generic member variable as part of a generic class
like this:

List<DLinqQuery <TDataContext >> _queries;

where DLinqQuery is a generic class that takes a type parameter
TDataContext.

This member variable is part of a generic class called
DLinqDataSource <TDataContext > and is exposed as a public property of
the specified type.

It is assumed that all TDataContext types will be derived from the
concrete class DataContext.

Now, let's say I derive a class from DataContext called MyDataContext.

I the create two concrete classes like this:

public class MyDataQuery : DLinqQuery<MyDa taContext>{}
public class MyDataSource : DLinqDataSource <MyDataContext> {}

I want to be able to override the property in the MyDataSource class to
return a List<MyDataQuer y> instead of the generic
List<DLinqQuery <TDataContext >> which would become
List<DLinqQuery <MyDataContex t> in an instantiation of MyDataSource.

Unfortunately, casting the base property value (which is a
List<DLinqQuery <MyDataContext> > to the type List<MyDataQuer y> just
doesn't work, but from a functional perspective it seems like that it
would.

Any ideas on whether this can be done?

[Tom Spink]

ha************* ***@gmail.com wrote:

Hello,

I'm wondering if it's possible to do the following with Generics:

Let's say I have a generic member variable as part of a generic class
like this:

List<DLinqQuery <TDataContext >> _queries;

where DLinqQuery is a generic class that takes a type parameter
TDataContext.

This member variable is part of a generic class called
DLinqDataSource <TDataContext > and is exposed as a public property of
the specified type.

It is assumed that all TDataContext types will be derived from the
concrete class DataContext.

Now, let's say I derive a class from DataContext called MyDataContext.

I the create two concrete classes like this:

public class MyDataQuery : DLinqQuery<MyDa taContext>{}
public class MyDataSource : DLinqDataSource <MyDataContext> {}

I want to be able to override the property in the MyDataSource class to
return a List<MyDataQuer y> instead of the generic
List<DLinqQuery <TDataContext >> which would become
List<DLinqQuery <MyDataContex t> in an instantiation of MyDataSource.

Unfortunately, casting the base property value (which is a
List<DLinqQuery <MyDataContext> > to the type List<MyDataQuer y> just
doesn't work, but from a functional perspective it seems like that it
would.

Any ideas on whether this can be done?

Hi,

This question has been asked a few times here. The answer I gave to one of
them was that you cannot cast it, because a List<A> is not, and is not a
derivative of a List<B> if A derives from B. They're two different types,
because the type is expressed as a result of the type name and it's type
parameters.

So, you'll have to write a function that will convert the
List<DLinqQuery <MyDataContext> > to List<MyDataQuer y>. Also, the definition
of override is to change the behaviour of a virtual method defined in a
base class, not to alter it's signature, e.g.:

public virtual bool foo ( int bar ) { ... }

Can only be overriden to change the behaviour of 'foo', not it's return
type, and not it's parameters.

The generic List class contains a generic method called ConvertAll<> which
can help you convert the list, or you can just enumerate through your list
and build a brand new one.

--
Hope this helps,
Tom Spink

[Jon Skeet [C# MVP]]

Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard .caspershouse.c omwrote:

The reason you can not do this is because generic types are not
covariant (I believe that is the term).

It is - although the CLR itself supports covariance. You can tell the
CLR that something is a list of "some type which is derived from Dog"
or "some type which is a super-type of Dog". However, C# doesn't expose
this, and neither do the framework libraries.

It's a bit of a shame - the Java libraries *do* expose this, and
although it's a fairly confusing topic, it can be very handy. With Mads
on the C# team now, I wouldn't be surprised to see
covariance/contravariance appear in a later version - although now the
standard libraries have been defined without support, the usefulness of
them would be very much diminished.

(I should say that this is one of the very few places where Java
generics are better than C# generics.)

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

[Tom Spink]

Jon Skeet [C# MVP] wrote:

Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard .caspershouse.c omwrote:

> The reason you can not do this is because generic types are not
covariant (I believe that is the term).

It is - although the CLR itself supports covariance. You can tell the
CLR that something is a list of "some type which is derived from Dog"
or "some type which is a super-type of Dog". However, C# doesn't expose
this, and neither do the framework libraries.

It's a bit of a shame - the Java libraries *do* expose this, and
although it's a fairly confusing topic, it can be very handy. With Mads
on the C# team now, I wouldn't be surprised to see
covariance/contravariance appear in a later version - although now the
standard libraries have been defined without support, the usefulness of
them would be very much diminished.

Hi Jon,

(I should say that this is one of the very few places where Java
generics are better than C# generics.)

I agree with that, very reluctantly. I've always found Java generics nasty,
since it's not a feature of the JVM, but a feature of the compiler,
unlike .NET which is a feature of the CLI, not the compiler, which IMHO,
the latter feels nicer. <g>

--
Hope this helps,
Tom Spink

[Jon Skeet [C# MVP]]

Tom Spink <ts****@gmail.c omwrote:

(I should say that this is one of the very few places where Java
generics are better than C# generics.)

I agree with that, very reluctantly. I've always found Java generics nasty,
since it's not a feature of the JVM, but a feature of the compiler,
unlike .NET which is a feature of the CLI, not the compiler, which IMHO,
the latter feels nicer. <g>

It's certainly better to be part of the platform itself (although it's
still a feature of the compiler, of course. If the compiler doesn't
support generics, you're not going to be able to use them). I'd say
it's still nicer to have Java-style generics than not to have them at
all, but it would have been much better to have .NET-style generics,
even without covariance.

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

[Barry Kelly]

Jon Skeet [C# MVP] <sk***@pobox.co mwrote:

Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard .caspershouse.c omwrote:

The reason you can not do this is because generic types are not
covariant (I believe that is the term).

It is - although the CLR itself supports covariance. You can tell the
CLR that something is a list of "some type which is derived from Dog"
or "some type which is a super-type of Dog". However, C# doesn't expose
this, and neither do the framework libraries.

It's a bit of a shame - the Java libraries *do* expose this, and
although it's a fairly confusing topic, it can be very handy. With Mads
on the C# team now, I wouldn't be surprised to see
covariance/contravariance appear in a later version - although now the
standard libraries have been defined without support, the usefulness of
them would be very much diminished.

(I should say that this is one of the very few places where Java
generics are better than C# generics.)

A problem with enabling covariance and contravariance is that it would
add type-checks at the CLR level to operations which currently don't
need a type-check. For example, covariance of object arrays is enabled
in C#. As a result, all writes into an object array cause a runtime
type-check.

The type-safe way to enable covariance and contravariance is to limit
the methods callable on a generic parameter explicitly allowed to accept
covariant or contravariant values. Basically, variables of a covariant
type are allowed to return the covariant type in out or return
parameters only, while variables of a contravariant type are allowed to
accept values of a contravariant types only.

There is good coverage of this issue in a recent MS paper:

Variance and Generalized Constraints for C# Generics
Burak Emir, Andrew J. Kennedy, Claudio Russo, Dachuan Yu
July 2006

http://research.microsoft.com/resear...edings&id=1215

Direct link:
http://research.microsoft.com/~akenn...cs/ECOOP06.pdf

Discussion on Lambda the Ultimate:

http://lambda-the-ultimate.org/node/1573

-- Barry

--
http://barrkel.blogspot.com/

[Jon Skeet [C# MVP]]

Barry Kelly <ba***********@ gmail.comwrote:

(I should say that this is one of the very few places where Java
generics are better than C# generics.)

A problem with enabling covariance and contravariance is that it would
add type-checks at the CLR level to operations which currently don't
need a type-check. For example, covariance of object arrays is enabled
in C#. As a result, all writes into an object array cause a runtime
type-check.

That's one sort of covariance, yes.

The type-safe way to enable covariance and contravariance is to limit
the methods callable on a generic parameter explicitly allowed to accept
covariant or contravariant values. Basically, variables of a covariant
type are allowed to return the covariant type in out or return
parameters only, while variables of a contravariant type are allowed to
accept values of a contravariant types only.

That's the sort of covariance/contravariance I was thinking of :)
Perhaps there ought to be two different terms for it...

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

[Barry Kelly]

Jon Skeet [C# MVP] <sk***@pobox.co mwrote:

Barry Kelly <ba***********@ gmail.comwrote:

(I should say that this is one of the very few places where Java
generics are better than C# generics.)

A problem with enabling covariance and contravariance is that it would
add type-checks at the CLR level to operations which currently don't
need a type-check. For example, covariance of object arrays is enabled
in C#. As a result, all writes into an object array cause a runtime
type-check.

That's one sort of covariance, yes.

The type-safe way to enable covariance and contravariance is to limit
the methods callable on a generic parameter explicitly allowed to accept
covariant or contravariant values. Basically, variables of a covariant
type are allowed to return the covariant type in out or return
parameters only, while variables of a contravariant type are allowed to
accept values of a contravariant types only.

That's the sort of covariance/contravariance I was thinking of :)
Perhaps there ought to be two different terms for it...

If one describes reading from an array as a method "T GetValue(int)",
and writing into an array as "void SetValue(int, T)", then there is an
exact correspondence between covariance/contravariance in classes and
covariance in arrays, as described above. They're the same thing. The
SetValue(int, T) method should be contravariant, not covariant - e.g.
considering arrays of dogs and mammals, if SetValue() is going to be the
only "method" called on the array, then one should be able to supply an
array of mammals where an array of dogs is expected. Slightly
counter-intuitive, perhaps, but that's where the "contra" comes in :)

The paper gives good coverage of a possible way of introducing it into
C#. My only concern is that it would confuse things, since reasoning
about covariance / contravariance can be a little tricky.

-- Barry

--
http://barrkel.blogspot.com/

[Jon Skeet [C# MVP]]

Barry Kelly wrote:

That's the sort of covariance/contravariance I was thinking of :)
Perhaps there ought to be two different terms for it...

If one describes reading from an array as a method "T GetValue(int)",
and writing into an array as "void SetValue(int, T)", then there is an
exact correspondence between covariance/contravariance in classes and
covariance in arrays, as described above. They're the same thing.

Not quite (IMO). The CLR supports covariance/contravariance by allowing
a type to be declared as List<Stream+or List<Stream-for instance.
That is a sort of *declarative* covariance/contravariance which can
tell the compiler that it *will* support one of GetValue or SetValue
(and which one :) That's not the same as the runtime
covariance/contravariance of arrays in terms of compile-time type
safety, so it's worth making the distinction between them. The CLR
supports compile-time-unsafe covariance for arrays, but
compile-time-safe covariance/contravariance for generics. C# supports
compile-time-unsafe covariance for arrays, but has no concept of the
compile-time-safe generic covariance/contravariance supported by the
CLR.

Does that explain the distinction I make between the two sorts of
covariance any better?

Jon