Identical objects in a list produce different hashes and fail comparison tests

Question

I have a weird issue. I want to implement an extension to List with a function to merge another list into it excluding the duplicate values:

    <Extension()>
    Public Sub AddUnique(Of T)(ByVal self As IList(Of T), ByVal items As IEnumerable(Of T))
        For Each item In items
            If Not self.Contains(item) Then self.Add(item)
        Next
    End Sub

Now, I have a class that I'll be creating objects from, and adding them to a list:

    Class DocInfo
        Public Property title As String
        Public Property fullPath As String

        Sub New(title As String, fullPath As String)
            Me.title = title
            Me.fullPath = fullPath
        End Sub
    End Class

Then, I have a list as a global variable:

Public docsInfo As New List(Of DocInfo)

And then I have a button handler that adds new items to that list:

Private Sub AddToList_Button_Click(sender As Object, e As RoutedEventArgs)
    Dim candidateItems As New List(Of DocInfo)
    For Each doc In selectedDocs
        candidateItems.Add(New DocInfo(doc.GetTitle(), doc.GetPathName()))
    Next

    docsInfo.AddUnique(candidateItems)
End Sub

(The doc and selectedDocs variables are outside of the scope of this question.)

Now, the important bit - GetTitle() and GetPathName() return the same strings on every button click (I have the same docs selected between clicks). Meaning that DocInfo objects that are added to the candidateItems, and then added to docsInfo, are identical. Nevertheless, the extension function AddUnique fails, resulting in duplicates in the list.

Puzzled, I ran GetHashCode() on these duplicate DocsInfo class objects:

    For Each docInfo In docsInfo
        Console.WriteLine(docInfo.title)
        Console.WriteLine(docInfo.fullPath)
        Console.WriteLine(docInfo.GetHashCode())
    Next

And this is the output:

Assem1^Test assembly.SLDASM
C:\Users\Justinas\AppData\Local\Temp\swx5396\VC~~\Test assembly\Assem1^Test assembly.SLDASM
7759225

Assem1^Test assembly.SLDASM
C:\Users\Justinas\AppData\Local\Temp\swx5396\VC~~\Test assembly\Assem1^Test assembly.SLDASM
14797678

With each button click, I am getting identical DocsInfo objects (title and fullPath properties have the same values), yet their hashes are different every time, and every comparison I can think of, fails to acknowledge that these objects are for all intents and purposes idendical.

Why is this happening? And how can I fix the AddUnique extension function to work as intended?

Answer 1

This behavior is because of the difference in .NET between "Reference" types and "Value" types. The fundamental philosophy of these is that for "Reference" types, object identity takes precedence over contents (that is, two different object instances with the same contents are still considered distinct), while for "Value" types, the contents are the only thing that matters.

In VB, Class denotes a reference type while Structure denotes a value type. Their respective behaviors are what you would expect, then: by default, Equals on a Class is equivalent to ReferenceEquals, checking to see if the references are the same, and GetHashCode returns a value based on the object identity. Equals on a Structure does member-wise value equality, and GetHashCode returns a value based on the hash codes of the members.

There are a couple of different options for overriding the default behavior, with differing impacts and levels of intrusiveness.

You can change Class to Structure. If you do so, I would strongly recommend to eliminate any mutable behavior on them (i.e. make all fields and properties ReadOnly), because mutable Structures can be extremely hard to reason about correctly. If you really do have immutable data, though, this is the easiest to maintain because .NET will already do what you want, you don't have to maintain your own Equals or GetHashCode override.

You can override GetHashCode and Equals on your Class to act like the Structure versions. This won't change anything else about your class, but it will make it act like a value type for the purposes of containers and sequences. If you're worried about maintenance, an alternative would be to do something reflection-based, though this shouldn't be used for anything that will be high-throughput because reflection is generally not particularly performant.

I believe the hashing and ordering containers take optional constructor parameters that will let you provide a class for overriding the behavior of the contents without altering the Class itself. You could do something like this. I'd recommend to look at the MSDN docs for HashSet.