[Mono-bugs] [Bug 75408][Nor] New - .NET 2.0: Type.FullName should return NULL whenever Type.IsGenericParameter or Type.ContainsGenericParameters is true

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by gert.driesen at pandora.be.

http://bugzilla.ximian.com/show_bug.cgi?id=75408

--- shadow/75408	2005-06-28 13:12:58.000000000 -0400
+++ shadow/75408.tmp.5390	2005-06-28 13:12:58.000000000 -0400
@@ -0,0 +1,55 @@
+Bug#: 75408
+Product: Mono: Runtime
+Version: 1.1
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Normal
+Component: misc
+AssignedTo: mono-bugs at ximian.com                            
+ReportedBy: gert.driesen at pandora.be               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: .NET 2.0: Type.FullName should return NULL whenever Type.IsGenericParameter or Type.ContainsGenericParameters is true
+
+I submitted a bug report to the MSDN Product Feedback Center as 
+Type.FullName returned NULL for some generic types. But apparently, this 
+appears to be by design:
+
+"Type.FullName returns null whenever Type.IsGenericParameter or 
+Type.ContainsGenericParameters is true. The most important invariant for 
+Type.FullName is that Type.FullName + assembly spec must equal 
+Type.AssemblyQualifiedName which means that FullName must uniquely 
+identify a type in an assembly. So the rational for returning NULL in the 
+aforementioned cases is that and it is not a simple matter to identify a 
+generic type parameter (and therefore types instantiated with them) as 
+they could be declared on Methods which would require their 
+identification and hence Type.FullName to include method signatures. For 
+example FullName for T in this case would be messy to represent:
+
+class C 
+{
+void M<T>(Foo foo);
+}
+
+GenericParameters are serializable because we already have logic to 
+identify MethodInfos. 
+
+This is not a problem with ToString however it is possible to create two 
+types that have the same ToString but are not equivalent. For example:
+
+class B<T> { }
+class D<T> : B<T> { }
+typeof(B<T>).ToString() == typeof(D<T>).BaseType.ToString
+typeof(B<T>) != typeof(D<T>).BaseType
+
+These types share the same ToString because their generic parameters are 
+given the same name T but if one is changed to S it becomes clear that 
+the two Type objects do indeed represent different locations."
+
+http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?
+feedbackid=43e19db4-f2a9-4cf2-81d4-004ca6a36e57