Suggestion: HashSet.add should always update/set key value, regardless of equality

[timdown]

Suggestion: HashSet.add should always update/set key value, regardless of equality

[GoogleCodeExporter]

Interesting. I'm not sure which I'd expect, and I'm not sure what would happen 
in the equivalent situation in Java or C#. Do you happen to know? (I will try 
it later when I have a little more time).

Original comment by [email protected] on 17 Oct 2010 at 4:38

[GoogleCodeExporter]

No, don't know how other implementations deal with this. From the perspective 
of HashTable I wouldn't know what to expect either. But from the perspective of 
a HashSet I'd expect keys to be updated/overwritten, as they are not keys in 
that scenario, but values.

Original comment by [email protected] on 17 Oct 2010 at 4:42

[GoogleCodeExporter]

I've thought about this and decided that I prefer the current behaviour. Your 
example fundamentally defines o1 and o2 as being equal in terms of the set so 
are essentially interchangeable. If you do actually need to distinguish between 
o1 and o2 then you need to rewrite your equality function to do that.

For what it's worth, C#'s HashSet implementation does the same thing.

Original comment by [email protected] on 18 Oct 2010 at 8:03

• Changed state: WontFix

[GoogleCodeExporter]

Ok, understand your reasons.

But the implication is that there is no way of obtaining a particular value 
from the set, apart from cluelessly iterating over them all. Wouldn't it be an 
idea to offer a means of doing just that?

Original comment by [email protected] on 18 Oct 2010 at 8:29

[GoogleCodeExporter]

What's happening in your example is that o2 is never being added to the set 
because it thinks it's already in there (since it's equal to o1). There's only 
one element in the set.

Original comment by [email protected] on 18 Oct 2010 at 9:12

[GoogleCodeExporter]

Yes I understand that. My point is that o1 is out of reach as soon as it is in 
the set. Your only option is to remove it, but the object will be lost (and 
garbage collected) because no reference to it is returned.

Original comment by [email protected] on 18 Oct 2010 at 9:25

[GoogleCodeExporter]

OK, sorry. So your problem is that you can't tell without iterating over the 
set whether o1 or o2 is in it. So if the actual object identity is important, 
why have you defined the equality function not to distinguish between different 
object with the same id property?

Original comment by [email protected] on 18 Oct 2010 at 9:46

[GoogleCodeExporter]

My use case:

STORE = new Hashset();
var p1 = new Person();
p1.setData({id: 1, name: "Tim"});  // this data might come from server
STORE.add(p1);

// and then in another part of the application:
var p2 = new Person();
p2.setData({id: 1, name: "Tim Molendijk"});  // this data might come from a web 
form
if (STORE.contains(p2)) {
  var p = STORE.get(p2);  // this is currently not possible
  p.setData(p2.getData());
} else {
  STORE.add(p2);
}

Original comment by [email protected] on 18 Oct 2010 at 10:09

[GoogleCodeExporter]

OK, I see what you're getting at. Thanks for the example. Couldn't you instead 
use a Hashtable keyed by id?

Original comment by [email protected] on 19 Oct 2010 at 11:50

[GoogleCodeExporter]

Yeah I'm using Hashtable instead. No problem. Just thought I'd share it because 
I'm basically using it as a set data structure. Which is what the HashSet 
wrapper was created for I suppose.

Anyway, thanks a lot.

Original comment by [email protected] on 19 Oct 2010 at 11:58

[GoogleCodeExporter]

I've had a change of heart on this. Issue 5 is a duplicate and I've decided to 
add an option to enable duplicate key replacement in the next version.

Original comment by [email protected] on 15 Jul 2013 at 11:19

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by [email protected] on 15 Jul 2013 at 11:19

• Changed state: Duplicate