ModelExtensions.AreSame violates it's contract "True if object properties are the same" (sort of)

Jan 24, 2012 at 7:11 PM
Edited Jan 24, 2012 at 7:41 PM

Hi,

I stumbled across a problem, that the ViewModelDetailBase.IsDirty was false but the Model was modified. I checked the calculating of ModelExtensions.AreSame() and found a hash collision.

These hashes have been calculated:

469480012 | -1549677631 | -1141113907 | 660945483 | -1073742897 | -843663477 | -49 | -842352752 | -33 | 30 = -33

-1587134374 | -761976430 | -201889318 | 660945482 | -134775846 | -843401333 | -37 | -842352752 | -37 | 30 = -33

The current implementation violates the contract. Well, not exactly as it does not state "True if object properties are the same, false otherwise". But it is pretty useless for equality checking (and IsDirty) when you can't rely on true if and only if the properties are the same and maybe losing changes.

As by definition the same hash code does not necessarily indicate that the objects are equal, what about comparing equality of the Original and the Clone property by property? We could then return false with the first difference found.

What do you think? Is this an issue?

Coordinator
Feb 28, 2012 at 8:29 PM

Good catch I think.  I'm working on a new version of the toolkit that uses Silverlight 5.  I'll take you up on your recommendation and try a property-by-property comparison.  There might be a slight performance hit by using reflection, but at least the results will be predictable. ;-)

Coordinator
Oct 19, 2012 at 10:34 PM
Edited Nov 8, 2012 at 3:03 PM

Using a logical XOR (^) instead of XOR (|) in GetHashCode seems to address this issue.

I fixed this issue in v3.1.0.0 of the toolkit