The Moth

We are all familiar with the Type class of the framework and how useful it is in many scenarios. To obtain the Type of a type we can call GetType() on the instance, the static Type.GetType passing in the full name, or use C#'s typeOf operator (or GetType operator in VB).

We are also familiar with Generics (supported on NETCF as well).

At first there isn't much relation between the two. There are some cases, though, when you design an API (that depends on a type to be passed to it) where either of the two can satisfy your goal: A generic class or a class with a constructor accepting a Type. So in that case, which approach should you choose and why?

1. Blah<T>{...} //type declaration
2. Blah(Type t); //ctor

Just to be ultra-clear, the calling code for each occasion looks something like this:
1. new Blah<SomeType>();
2. new Blah(typeOf(SomeType));

Just FYI, and don't allow this to affect your thoughts, the indigo (or WCF if you prefer) team chose the 1st approach originally and then, after Beta 1, changed to the second. I am referring, of course, to the ServiceHost class. Why did they do that?

Since this blog doesn't have comments, reply on your own blog (or if you don't have one, feel free to email me your reply).

UPDATE:
1) .NET design guidelines guru provides comments.
2) Ayende describes his preferences
3) Apparently, there is no mystery on the Indigo change:
"The ServiceHost just needs to know the type of the object being hosted - none of the methods or properties were accepting or returning the so the generic mechanism wasn't really being using per se."