Generics

This morning I read a post about the .NET design guidelines and I am upset about the last line of this guideline. We are now going to have people choosing generics over polymorphism to solve a problem.  If I expect an ISession for the paramter of my method, class etc, why would that become a generic?  Maybe I am completely missing something here.  So I turn my chair around and start ranting to Peter and Brian to unleash my angry coder feelings.  It took a while for me to understand that generics are not templates and now I understand the need for typesafe containers so I can get T back from a method of class Foo<T>.  I just don't understand the need to put the responsibility of limiting T on the class.  If I want a generic sort algorithm, that should be outside of the container ala STL. Of course I also keep thinking when we get iterators in C# that we are getting C++ iterators and again, sadly, I am disappointed, so I understand the need, I just don't agree with the solution.

I understand that generics are not templates, but why not?  I think Stan Lippman's post hits in on the head.

So to get back to the real point of this post, using descriptive names for template paramters seems to support something that should be purged from the system, which are large classes, methods etc.  I belive in naming variables for what they are, but if you have a template and you can't see the name of the template parameter anymore, you probably have a method that is too long, or need unusually large fonts for accesiblity reasons. Objects are cheap and the methods in them should be short.  I am in favor of a bunch of small classes with specific responsiblities and small methods.

Don't get me wrong, I like C# and the direction it is heading, yet as a wise man Brian Button says "All languages tend toward C++".  And I tend to agree with him. I think the guys on the C++ 2.0 team are going to get it right and make some big waves in the world.  If you are interested in these types of things read here.

All that being said, this is my personal opinion and in no way implies the opinion of Microsoft.

Comments

• Anonymous
  November 05, 2004
  The comment has been removed
• Anonymous
  November 05, 2004
  Red flags were definitely raised when I first saw the type constraint "feature" of generics. I guess the use case is where you need to constrain a type and do operations on that type polymorphically within your class, but want to avoid casting of the specific type when implementing that class. However, I'm not convinced that this is a valid approach.
• Anonymous
  November 05, 2004
  Polymorphism is the ability of an object to assume a more abstract form. Generics do not provide quite this capability. For instance:
  
  LionPen can be cast to AnimalPen...
  
  ...but Pen<Lion> cannot be cast to Pen<Animal>.
  
  In the latter case, if you wanted a type-safe way of referring to Pen<Lion>, Pen<Elephant>, or Pen<Penguin> using the same variable, you'd have to declare an abstract Pen type, and have Pen<Animal> derive from it:
  
  public abstract class Pen
  {
  public abstract Animal Animal {get;}
  }
  
  public class Pen<Animal>: Pen
  where Animal: Animal
  {
  ...
  }
  
  In other words, you'd have to fall back to polymorphism, even if you limit the type parameter.
  
  Generics solve a different set of problems than polymorphism does. It addresses the performance defects of using value types with collections, and it dramatically reduces the amount of code required to create classes that are on the same level of abstraction.
  
  Polymorphism targets a different problem--that of facilitating the interaction of classes on different levels of abstraction.
  
  They complement each other.
• Anonymous
  November 05, 2004
  The parameter typing can be a big benefit because it gives you a lowest-common denominator when accessing objects of that type. You can then call methods/access properties on that generic parameter w/o casting.
  
  I have a common base class used by several generic classes, and i'm able to assume that the parameters of type 'T' support this common denominator of methods/properties.