Partager via

Answer of the month: Type.FullName

  • Article

Answer: It will assert.

Why: Well, first of all... there is one big reason why the assert would fire. "t1" refers to something that has to do with the DerviedClass, and "t2" refers to something that has to do with the BaseClass.

Good job Barry for noticing it. I agree with Barry, my quiz was not planned very well. (I promise to author a better quiz for May.) What I want to highlight in this example is the fact that Type.FullName returns null when the type contains generic parameters.

As Barry has mentioned, a better example is:

Type t1 = typeof(DerivedClass<>).BaseType;
Type t2 = typeof(BaseClass<>);

Anyways, with my example, what you get is this:

fullName1 = "DerivedClass`1"
fullName2 = null

Why is the FullName of t1.BaseType null?

The BaseType of DerivedClass<T> does not equal BaseClass<T>. If we use a differnt name for the generic variable in DerivedClass, you'll see why. Suppose you use S:

Foo<S>

Then the BaseType of DerivedClass is BaseClass<S>. Any type which is not a generic type definition and containsGenericArguements = true will not have a FullName because we do not provide a syntax for resolving generic paramenters. Why didn't we provide a syntax you may ask... This is because the general problem is made difficult in the case where the generic parameter belongs to a method. In order to identify the generic paramenter, we'll have to provide overload resolution. In this example, what would you expect the Fullname to be for the instatiation Foo<S> given the defintion:

class Foo<T>
class Class
   void Bar<S>()
   void Bar<R>(int i)

Also, Haibo also talked about it here.

Comments