GetHashCode issue

[Patrick Hertzog]

I've an issue when overriding GetHashCode methods. For instance, an
hypothetical Circle object may have its hashcode defined as x ^ y ^ diameter.
This works fine as long as the object is not modified (otherwise it doesn't
work).

Microsoft states the following: "The hash function must return exactly the
same value regardless of any changes that are made to the object". It means
that you should base your hashcode on properties that will not change. How to
proceed when all the properties can change (as in the above Circle)? Define a
"fake" constant property? How to define it? Or has someone a elegant strategy?

Thanks in advance!!

[Senthil Kumar]

I can't see any other way other than making Circle immutable (like
String). If the user wants to modify, he/she must create a new instance
(Clone()?).

Regards
Senthil Kumar

[Patrick Hertzog]

Thanks! But actually the object in question is not as simple as Circle ;-) so
I would like to avoid to duplicate it if possible... but maybe it is not
possible!

"Senthil Kumar" wrote:

I can't see any other way other than making Circle immutable (like
String). If the user wants to modify, he/she must create a new instance
(Clone()?).

Regards
Senthil Kumar

[Michael S]

"Patrick Hertzog" <Patrick He*****@discussions.microsoft.com> wrote in
message news:45**********************************@microsof t.com...

I've an issue when overriding GetHashCode methods. For instance, an
hypothetical Circle object may have its hashcode defined as x ^ y ^
diameter.
This works fine as long as the object is not modified (otherwise it
doesn't
work).

Microsoft states the following: "The hash function must return exactly the
same value regardless of any changes that are made to the object". It
means
that you should base your hashcode on properties that will not change. How
to
proceed when all the properties can change (as in the above Circle)?
Define a
"fake" constant property? How to define it? Or has someone a elegant
strategy?

Thanks in advance!!

Never underestimate the power of GUID's

=)

- Michael S

[Patrick Hertzog]

Maybe a little bit more explanation about GUID's or a example could help me
not to underestimate them! ;-)

"Michael S" wrote:

"Patrick Hertzog" <Patrick He*****@discussions.microsoft.com> wrote in
message news:45**********************************@microsof t.com...

I've an issue when overriding GetHashCode methods. For instance, an
hypothetical Circle object may have its hashcode defined as x ^ y ^
diameter.
This works fine as long as the object is not modified (otherwise it
doesn't
work).

Microsoft states the following: "The hash function must return exactly the
same value regardless of any changes that are made to the object". It
means
that you should base your hashcode on properties that will not change. How
to
proceed when all the properties can change (as in the above Circle)?
Define a
"fake" constant property? How to define it? Or has someone a elegant
strategy?

Thanks in advance!!

Never underestimate the power of GUID's

=)

- Michael S

[Lebesgue]

"Patrick Hertzog" <Patrick He*****@discussions.microsoft.com> wrote in
message news:79**********************************@microsof t.com...

Maybe a little bit more explanation about GUID's or a example could help me not to underestimate them! ;-)

"Michael S" wrote:

Maybe a simple google search would help you
http://msdn.microsoft.com/library/de...wguidtopic.asp

Guid is an absolute unique identifier

[C#]
public static Guid NewGuid();

use
this.myGuid = Guid.NewGuid();

and use Guid's hashcode for hashing your objects

[Patrick Hertzog]

Thanks a lot for your help!

"Lebesgue" wrote:

"Patrick Hertzog" <Patrick He*****@discussions.microsoft.com> wrote in
message news:79**********************************@microsof t.com...

Maybe a little bit more explanation about GUID's or a example could help

me

not to underestimate them! ;-)

"Michael S" wrote:

Maybe a simple google search would help you
http://msdn.microsoft.com/library/de...wguidtopic.asp

Guid is an absolute unique identifier

[C#]
public static Guid NewGuid();

use
this.myGuid = Guid.NewGuid();

and use Guid's hashcode for hashing your objects

[Patrick Hertzog]

Thanks a lot Bruce!! Very valuable explanation!!!

"Bruce Wood" wrote:

Normally mutable objects (such as your "Circle" example) are not good

candidates for keys in Hashtables.

I disagree.

The problem that Patrick is facing here is one of semantics. That is,
what exactly is his hypothetical circle object in business terms, and
what does that imply about its identity, and about hashing it.

I see three possibilities:

1. The object (such as a circle) is what I would consider a value type.
Talking about a particular instance as having an identity different
from other instances does not make sense. For example, talking about
"this particular integer value 5" versus "that integer value 5 over
there" doesn't ring true. The value 5 is the value 5, and it makes no
sense to put it in a hash table. One could design a circle in the same
way: "this is a circle of radius 5, and it makes no sense to talk about
'this circle of radius 5' versus 'that circle of radius 5'." A value
type is typically a property of some other thing that has an identity;
it has no identity of its own, so you would hash on the identity of the
owner object.

2. The object has a unique identity. For example, a particular circle
that the user has drawn at particular coordinates with a partiuclar
colour. This is a case in which you want to assign the object a UID
that has nothing to do with its radius, location, or colour, because no
matter what happens to the circle, you want to clearly distinguish
between this circle and that other circle. Even if the user drew them
at the same location with the same radius and same colour, thay are
distinct objects.

3. You may wish to hash the second type of circle (the one with a clear
identity) by location, or some such thing, for lookup purposes. It is
in this case that you are hashing on mutable properties, and you need
to adopt a smart system such as the one that Jay outlined in order to
manage the lookup table as the circle's properties change. However, the
hash table is a convenience measure, not a hash on identity, and there
may be other ways to get the same effect without the complexity of
managing mutable hash keys.

So, you have to ask yourself:

1. Does the object I'm working with have an identity? Does it make
sense to distinguish between two otherwise identical objects because
they represent real world things that are dinstinct even if all of
their qualities are the same?

2. Am I hashing on identity, or as a convenient lookup on some quality
of the object that may change? If it's the latter, is there another way
to get the same convenience without having to worry about hashing on
mutable keys? If it's the former, and the object has no obviously
unique, immutable data on which to base a hash key, then you probably
need a UID.

[Bruce Wood]

As an additional note, the way I usually handle the last case is via a
specialized collection.

To continue our example, if I have a circle that has an identity (and
therefore a UID), and I want a convenient lookup by colour, or by
location, or something like that, then I can't use GetHashCode().
GetHashCode() is for hashing on identity, and I already have a UID, so
I can't make a hash function that returns a hash based on location, at
least no without making the circle class act in a counter-intuitive
manner.

So, I cook up a CircleCollection class. CircleCollection offers lookup
based on UID (usually via an indexer), but offers additional lookup
functions for finding circles based on colour, location, area, etc. It
is then up to CircleCollection and Circle to cooperate on making that
all work. As a client of these classes I don't care how they do it.
CircleCollection can do a sequential search for all I care: I just want
the red circle(s).

This also hides the lookup implementation from the client and allows
you to change it later according to changing needs (more speed, less
memory, etc.)