Simulated Covariance for .NET Generics

re: Simulated Covariance for .NET Generics

Bill Sorensen — Wed, 02 Apr 2008 20:36:34 GMT

Interesting, thanks!

One typo:

// this of course does not complie

^^^^^

Also, the article says that

"in case of IEnumerable<object>, the object appears only in the output position"

and then

"in IEnumerable<T>, the T is at covariant positions (inputs). In List<T>, the T is at covariant and contravariant (output) positions."

It appears as though inputs and outputs were reversed.

re: Simulated Covariance for .NET Generics

Abraham Pinzur — Wed, 02 Apr 2008 21:53:56 GMT

I have encountered this situation in the past, and look forward to having your perspective to inform my design in the future. Thanks for sharing!

re: Simulated Covariance for .NET Generics

Jonathan Pryor — Wed, 02 Apr 2008 22:22:52 GMT

It's a good idea to document this pattern in the FxDG, as I independently reinvented this pattern (poorly) while helping someone on IRC recently...

What should also be mentioned, perhaps in a sidebar, are ways to avoid this. In particular, the C# Annotated Standard section 25.7 has a "Using constraints to simulate Java wildcard types" sidebar, ways to (ab)use the C# constraint mechanism to support collections of types rooted at some base type.

Thus, if PrintItems() can be made generic, it can be written as:

static void PrintItems<T> (IEnumerable<T> anyList)

{

foreach (object obj in anyList)

Console.WriteLine (obj.ToString ());

}

This suffers in that we must use generic methods to do this (compare to your original example where PrintItems() wasn't generic), but this is something that should be more widely known, and documenting it in the FxDG would be useful.

- Jon

re: Simulated Covariance for .NET Generics

kcwalina — Wed, 02 Apr 2008 23:59:54 GMT

Bill, thanks for pointing out the errors. I updated the text.

re: Simulated Covariance for .NET Generics

kcwalina — Thu, 03 Apr 2008 00:15:03 GMT

Jon, great point! I should have included it in the guideline.

But, in addition of some perf overhead related to JITing separate methods for each T, you cannot use the trick for properties, ... and databinging APIs (properties) actually do need a single root.

re: Simulated Covariance for .NET Generics

qrli — Thu, 03 Apr 2008 05:45:31 GMT

It looks good. However, the .NET guideline doc is getting longer and longer. If it is too long and takes too much time for everyone to understand, it will not be so practical. I like the way C# enforce many usage by the language itself, instead of having to remember tons of patterns do the basic things right like in Java. My wish is that you great guys can solve that in the compiler one day. But for now, the pattern is a good walkaround.

re: Simulated Covariance for .NET Generics

Larry Lard — Thu, 03 Apr 2008 09:43:50 GMT

Looks like a useful pattern, but your particular motivating example is slightly shot down by your own final point

When you say in the example "// what type should ??? be?", the answer is given by

"CONSIDER using a non-generic root type, if such type is already available.

For example, List<T> implements IEnumerable for the purpose of simulating covariance."

??? should be IEnumerable. End of story in the context of that example.

re: Simulated Covariance for .NET Generics

Chris Nahr — Thu, 03 Apr 2008 10:10:33 GMT

"CONSIDER using a non-generic root type, if such type is already available."

Why would you restrict this recommendation to *available* non-generic interfaces? IFoo<Object> doesn't look right to me. Using Object as a type parameter clashes with the concept of .NET generics since every type is always an Object anyway.

Using <Object> would make sense if you could create a universally compatible "base type" from the *existing* generic type, but as you point out that's not possible -- you have to define a new interface anyway. And once you do that, why not drop the useless type argument altogether and just say IFoo?

That's how IEnumerable works for generic collections, and keeping that pattern seems preferable IMO.

re: Simulated Covariance for .NET Generics

Hardeep Virdee — Thu, 03 Apr 2008 11:24:52 GMT

Thanks for sharing - this is a great pattern which I have already found useful. Would have been a great addition to the book.

re: Simulated Covariance for .NET Generics

Ryanoffski — Thu, 03 Apr 2008 23:23:04 GMT

Regarding the first example:

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

IEnumerable<object> objects = names; // this won’t compile

foreach(object obj in objects){

Console.WriteLine(obj.ToString());

}

We can use LINQ to get the code to compile:

IEnumerable<object> objects = names.Cast<object>();

We can't achieve complete simulated covariance with Cast method, like what's required in the Foo example, but it's useful in simpler cases.

re: Simulated Covariance for .NET Generics

michhes — Fri, 04 Apr 2008 08:57:37 GMT

Definitely worthy for the book!!!

re: Simulated Covariance for .NET Generics

kcwalina — Sat, 05 Apr 2008 00:45:11 GMT

Larry, thanks for the feedback. I will try to use another example. I agree the list root might be confusing. But, it is a real propblem that we talked at one of the BCL meetings dseveral years ago and decided to have IEnumerable<T> extend IEnumerable (which was not the design early on). If we did not make the decision, you would not be able to use IEnumerable as the root for all collections.

re: Simulated Covariance for .NET Generics

kcwalina — Sat, 05 Apr 2008 00:52:31 GMT

Chris, the reason I think generic roots are preferable to non-generic roots (unless a non-generic root already exists) is that the CLI standard (and the current CLR implementation) already support variance annotations. If/Once main .NET languages start to support it, IFoo<T> will be much more useful than IFoo.

re: Simulated Covariance for .NET Generics

Palladinos Nick — Mon, 07 Apr 2008 10:44:02 GMT

One Typo

var foos = new List<IFoo>()

You declare the Type IFoo<T>

and Foo<T> : IFoo<object>

so, the correct code is

var foos = new List<IFoo<object>>()

re: Simulated Covariance for .NET Generics

kcwalina — Mon, 07 Apr 2008 19:22:43 GMT

Thanks Nick! I fixed it.

re: Simulated Covariance for .NET Generics

chris — Thu, 17 Apr 2008 22:01:29 GMT

Did you just write this pattern b/c you just happened to think it up recently, or is this a pattern that's used throughout the framework or other substantial projects that you want to officially codify by adding it to the design guidelines? In the case of the former, I'd prefer to keep the guidelines free of ad-hoc contributions that, while interesting, have not yet stood the test of time (that's makes it suitable for a blog entry but not for an official publication); in the case of the latter -- seems like it would be a decent addition -- particularly if you could cite examples of places/types in the framework or other major projects that implement the pattern.

A rash of bloggers

GarethJ's WebLog — Wed, 14 May 2008 07:34:31 GMT

Just lately there seems to be a veritable feast of new blog stuff about VSX (if you don't mind me switching

re: Simulated Covariance for .NET Generics

Victor Shulman — Sat, 24 May 2008 06:11:27 GMT

Krzysztof, it's an excellent point, about the potential harm of generalizing a modifiable collection.

However, if it were possible to generalize at (RO) interface level, that would go a ways toward supporting the "program-to-interface" practice. Here's what I mean:

public interface IDisplayable {

string Text { get; }

string Data { get; }

}

public class Base : IDisplayable {

public string Text { get { return Name; } }

public string Data { get { return Id.ToString(); } }

public string Name { get; set; }

public Guid Id { get; set; }

}

class Sub : Base {

...

}

public IList<IDisplayable> GetData()

{

return [...].ToList<Base>();

}

or:

public void FillGrid(IList<Base> source);

public void ShowData()

{

FillGrid([...].ToList<Sub>());

}

In the first example, we have a syntactically RO interface -- no chance of danger at all!

The second example, admittedly, is iffier: from the reading of it, we assume that there's no updates to the list, though nothing prevents us from sneaking in some silliness. Perhaps, the second example ought to be handled with an RO interface, as well.

In any case, my point is that, if we can assure the RO quality of the generalized collection, the language should be happy to support our desire to generalize, no?

Cheers,

Victor.