theburningmonk.com

I saw an inter­est­ing use of covari­ance today, con­sider an inter­face IMy­Class and an imple­ment­ing class MyClass:

   1: public interface IMyClass { }

   2:

   3: public class MyClass : IMyClass { }

If you want to con­vert an List<MyClass> to a List<IMyClass> you would nor­mally use the Enumerable.Cast method but did you know that you can also use C# 4’s sup­port for covari­ance in the type para­me­ter and do this instead:

   1: var original = new List<MyClass>();

   2:

   3: var converted = original.ToList<IMyClass>()

Funky, eh? ;-)

Though I think it’s a party trick best avoided for any pro­duc­tion code, for which you should still prefer:

   1: var converted = original.Cast<IMyClass>().ToList();

because:-

• it achieves the same result
• it is just as expressive
• it is the stan­dard way of doing this kind of con­ver­sions in LINQ
• it is under­stood by most C# devel­op­ers so unlikely to cause confusion

There’s another argu­ment for using Cast, in the case of use-defined implicit/explicit oper­a­tors. Imag­ine if you have another class which does not inherit from MyClass but defines an explicit oper­a­tor which allows you to cast an instance of MyClass:

   1: public class MyOtherClass

   2: {

   3:     public static explicit operator MyClass(MyOtherClass other)

   4:     {

   5:         return new MyClass();

   6:     }

   7: }

In cases like this, you won’t be able to use the covari­ance trick:

   1: void Main()

   2: {

   3:     var original = new List<MyClass>();

   4:

   5:     Console.WriteLine(original.GetType());                               // List<MyClass>

   6:

   7:     // cast here doesn't actually do anything

   8:     Console.WriteLine(original.Cast<IMyClass>().ToList().GetType());     // List<IMyClass>

   9:

  10:     // changes the compile type, works because of covariance

  11:     Console.WriteLine(original.ToList<IMyClass>().GetType());            // List<IMyClass>

  12:

  13:     // casts the objs to MyOtherClass using the defined convertor

  14:     Console.WriteLine(original.Cast<MyOtherClass>().ToList().GetType()); // List<MyOtherClass>

  15:

  16:     // this line won't compile.

  17:     // it doesn't work because this is not covariance, there's no inheritance

  18:     // relationship between MyClass and MyOtherClass

  19:     // Console.WriteLine(objs.ToList<MyOtherClass>().GetType());

  20: }

Ref­er­ences:

Stack­Over­flow ques­tion – Cast­ing List<T> – covariance/contravariance problem

Look­ing at these two images snapped right off MSDN, what do you notice?

.

.

.

that IEnumerable<T> extends IEnu­mer­able but IList<T> doesn’t extend IList!?

I know, pecu­liar isn’t it?

Turns out, it was for a good reason:

“A sequence of inte­gers can be treated as a sequence of objects, by box­ing every inte­ger as it comes out of the sequence. But a read-write list of inte­gers can­not be treated as a read-write list of objects, because you can put a string into a read-write list of objects. An IList<T> is not required to ful­fill the whole con­tract of IList, so it does not inherit from it.”

Inter­est­ing.

Found another inter­est­ing post on Eric Lippert’s blog, this one explain the ratio­nales behind why there’s no built-in Enumerable.ForEach exten­sion method, one which myself and no doubt many oth­ers had decided to imple­ment ourselves.

As he explains, there are two main philo­soph­i­cal rea­sons why he’s against such an exten­sion method:

“The first rea­son is that doing so vio­lates the func­tional pro­gram­ming prin­ci­ples that all the other sequence oper­a­tors are based upon. Clearly the sole pur­pose of a call to this method is to cause side effects.”

“The sec­ond rea­son is that doing so adds zero new rep­re­sen­ta­tional power to the lan­guage. Doing this lets you rewrite this per­fectly clear code:

foreach(Foo foo in foos){ state­ment involv­ing foo; }

into this code:

foos.ForEach((Foo foo)=>{ state­ment involv­ing foo; });

which uses almost exactly the same char­ac­ters in slightly dif­fer­ent order. And yet the sec­ond ver­sion is harder to under­stand, harder to debug, and intro­duces clo­sure seman­tics, thereby poten­tially chang­ing object life­times in sub­tle ways.”

Well, that clears a few things up, hear­ing from one of the guys on the C# com­piler team.

Ref­er­ences:

Eric Lip­pert – fore­ach vs ForEach