Why Type.Equals(t1, t2) and not the equality operator?

Question

Why must Type.Equals(t1, t2) be used to determine equivalent types, and not the equality operator (e.g. for VB.NET, t1 = t2)?

It seems inconsistent with other parts of the .NET API.

Example in VB.NET:

If GetType(String) = GetType(String) Then Debug.Print("The same, of course") End If

causes a compile-time error of "Operator '=' is not defined for types 'System.Type' and 'System.Type'."

Answer 1

Given the way types are loaded, that surprises me. Where did you hear this from?

The docs for System.Type.Equals(Type) suggest that it's comparing via the UnderlyingSystemType property, but I'm not sure under what circumstances two different Type objects would have the same underlying system type.

I'd be really interested to see an example where this mattered... my guess is that from anywhere in "user code" they'll be the same thing, but there may be some cunning BCL code where it matters.

Answer 2

Looking at the source code in Reflector, I can't see how Type.Equals(t1,t2) would be handled any differently than t1 = t2. (There is actually no Type.Equals; it will actually call Object.Equals).

In C#, T1 == T2 works just fine.

Answer 3

According to this, the VB equality operator does a value comparison, not a reference comparison. Using Type.Equals(t1,t2) forces it to do reference comparison. If t1 and t2 are types, I would think that either would work, but I'm a C# guy so what do I know. I'd probably prefer using the is syntax for known classes and IsInstanceOf, if I don't care about exact type match.

Typeof a Is Boolean

a.GetType().IsAssignableFrom( b.GetType() )

Answer 4

In VB.NET The Is is the language operator used to test type equality. Note that Type.Equals test whether two variable of the same type are pointed to the same object. As shown by the below example.

Public Class Form1

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim X As New TestObject
        Dim Y As New TestObject

        If X Is Y Then MsgBox("The Same 1")
        If Type.Equals(X, Y) Then MsgBox("The Same 2")

        X = Y
        If X Is Y Then MsgBox("The Same 3")

        If Type.Equals(X, Y) Then MsgBox("The Same 4")
    End Sub
End Class

Public Class TestObject
    Public Value As Double
End Class

This was done because the history of the 'equals' operator in the BASIC language. When Objects were introduced in VB4 IS was chosen to test for equality as it was felt that overloading equals would be problematic.

I suggest searching google and usenet for Paul Vicks comments on why some individual BASIC idioms were ported and why other were not. I believe in this case was to avoid confusion as VB.NET introduced

ObjectA = ObjectC 'which causes ObjectA to reference the same objects as referenced by ObjectC.

While in VB6 it was Set ObjectA = ObjectC

The same reason why when objects were introduced in VB4 IS and Set were used to deal with object instead of overloading equals.

Ultimately these quirks became part of the the Basic Way of coding.