13.07.2015 Views

C# in Depth

C# in Depth

C# in Depth

SHOW MORE
SHOW LESS
  • No tags were found...

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

106 CHAPTER 3 Parameterized typ<strong>in</strong>g with genericsNotice that the various options for both covariance and contravariance use moregenerics and constra<strong>in</strong>ts to express the <strong>in</strong>terface <strong>in</strong> a more general manner, or to providegeneric “helper” methods. I know that add<strong>in</strong>g a constra<strong>in</strong>t makes it sound lessgeneral, but the generality is added by first mak<strong>in</strong>g the type or method generic. Whenyou run <strong>in</strong>to a problem like this, add<strong>in</strong>g a level of genericity somewhere with anappropriate constra<strong>in</strong>t should be the first option to consider. Generic methods (ratherthan generic types) are often helpful here, as type <strong>in</strong>ference can make the lack of variance<strong>in</strong>visible to the naked eye. This is particularly true <strong>in</strong> <strong>C#</strong> 3, which has strongertype <strong>in</strong>ference capabilities than <strong>C#</strong> 2.NOTEIs this really the best we can do?—As we’ll see later, Java supports covarianceand contravariance with<strong>in</strong> its generics—so why can’t <strong>C#</strong>? Well, a lot of itboils down to the implementation—the fact that the Java runtimedoesn’t get <strong>in</strong>volved with generics; it’s basically a compile-time feature.However, the CLR does support limited generic covariance and contravariance,just on <strong>in</strong>terfaces and delegates. <strong>C#</strong> doesn’t expose this feature(neither does VB.NET), and none of the framework libraries use it. The<strong>C#</strong> compiler consumes covariant and contravariant <strong>in</strong>terfaces as if theywere <strong>in</strong>variant. Add<strong>in</strong>g variance is under consideration for <strong>C#</strong> 4,although no firm commitments have been made. Eric Lippert has writtena whole series of blog posts about the general problem, and what mighthappen <strong>in</strong> future versions of <strong>C#</strong>: http://blogs.msdn.com/ericlippert/archive/tags/Covariance+and+Contravariance/default.aspx.This limitation is a very common cause of questions on <strong>C#</strong> discussion groups. Therema<strong>in</strong><strong>in</strong>g issues are either relatively academic or affect only a moderate subset of thedevelopment community. The next one mostly affects those who do a lot of calculations(usually scientific or f<strong>in</strong>ancial) <strong>in</strong> their work.3.6.2 Lack of operator constra<strong>in</strong>ts or a “numeric” constra<strong>in</strong>t<strong>C#</strong> is not without its downside when it comes to heavily mathematical code. The needto explicitly use the Math class for every operation beyond the simplest arithmetic andthe lack of C-style typedefs to allow the data representation used throughout a programto be easily changed have always been raised by the scientific community as barriersto <strong>C#</strong>’s adoption. Generics weren’t likely to fully solve either of those issues, butthere’s a common problem that stops generics from help<strong>in</strong>g as much as they couldhave. Consider this (illegal) generic method:public T F<strong>in</strong>dMean(IEnumerable data){T sum = default(T);<strong>in</strong>t count = 0;foreach (T datum <strong>in</strong> data){sum += datum;count++;}Licensed to Rhona Hadida

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!