A hash set puzzler

[Daniel Pitts]

The solution of the problem is elegant,and it's a good idea.

I think it's possible to happen in real development requirement.

The problem itself is artificial and the solution is inelegant because
it adds complexity by using the wrong tools for the job.

It really should be a Map instead of a Set, since Map is designed for
look-up, and Set is designed for containment/iteration only.

 

[Daniel Pitts]

If you face a large legacy systems, you need to deal with similar
problems, in such circumstances this technique is not there to help?
At least in some occasions, it is useful.Right?

d0ngd0ng

This is exactly how legacy systems become unmaintainable! If you
keep-up the work to maintain the legacy system, it will not become legacy.

If you add fragile hacks like you've suggested, it becomes legacy MUCH
quicker.

 

[Lew]

d0ngd0ng,

You keep asking the same question and getting the same answer.

d0ngd0ng:
Lasse Reichstein Nielsen:

I hope not. I wouldn't let it past a commit-check where I work,
and would seriously scold the person who did it. "Naughty, nauthty,
naughty coder!".
Lew:
The problem as stated on the website is goofy.
The solution posted there is goofier still.

Patricia Shanahan:

More basically, if you care which of several equal objects you are
dealing with, maybe equals was defined incorrectly.
d0ngd0ng:

Patricia Shanahan:

It is an extremely bad, crude, inelegant and nasty technique. As
written, it has several bugs. Even in a cleaned-up form it breaks the
equals contract, one of the most important and pervasive contracts in
the whole of the Java API, twice over by making equals asymmetric and
non-reflexive.

It is also a way to avoid facing the real problem. If you are ever even
tempted to consider using this, please, please find the bug in the
design and fix it instead.
d0ngd0ng:

This is exactly how legacy systems become unmaintainable! If you
keep-up the work to maintain the legacy system, it will not become legacy.

If you add fragile hacks like you've suggested, it becomes legacy MUCH
quicker.

In other words, no, the technique in question is a very, very bad idea. It is
wrong to do that thing there. No matter how many times you ask if it's a good
idea, it will remain a bad idea.

 

[Patricia Shanahan]

If you face a large legacy systems, you need to deal with similar
problems, in such circumstances this technique is not there to help?
At least in some occasions, it is useful.Right?

I'd have to be pretty desperate to use something as fragile as an equals
that does not follow the contract specified in Object. I have trouble
seeing a situation in which this would work but one could not build a
more appropriate data structure in which the required operation would be
natural. For example, one could have a map with the exact object as
value, and use its keySet for the Set operations.

However, the whole situation seems very artificial to me, because it
depends on both wanting to have a set containing at most one element
from each equals equivalence class, and yet caring which of the equal
objects is in the set.

Patricia

 

[d0ngd0ng]

d0ngd0ng,

You keep asking the same question and getting the same answer.

d0ngd0ng:


Lasse Reichstein Nielsen:


Patricia Shanahan:


Patricia Shanahan:





In other words, no, the technique in question is a very, very bad idea. It is
wrong to do that thing there. No matter how many times you ask if it's a good
idea, it will remain a bad idea.

I have to say that I have been speechless, re-find it an interesting
topic.
Thank you $B!'!K(B

 

[shortcutter]

In other words, no, the technique in question is a very, very bad idea. It is
wrong to do that thing there. No matter how many times you ask if it's a good
idea, it will remain a bad idea.

Well, sometimes even strange things happen - like with this
mathematician at the university who found an epsilon which was so
small that it became negative when divided by two. ;-)

Cheers

robert