Re: hashCode
On 12.08.2012 22:59, Arne Vajh=F8j wrote:
On 8/12/2012 11:06 AM, Robert Klemme wrote:
On 11.08.2012 01:27, Arne Vajh=F8j wrote:
On 8/10/2012 6:22 PM, bob smith wrote:
On Friday, August 10, 2012 11:34:28 AM UTC-5, Eric Sosman wrote:
On 8/10/2012 11:47 AM, bob smith wrote:
Is it always technically correct to override the hashCode function=
like so:
@Override
public int hashCode() {
return 1;
}
Would it be potentially better if that was Object's implementation=
?
Define "better."
Better in the sense that you would never HAVE to override hashCode.
Now, there are cases where you HAVE to override it, or your code is
very broken.
It is not broken.
It will perform poorly in many cases.
Well, I would go as far as to say that it will perform poorly in all
cases where hashCode() is actually needed
More or less.
- and that makes it broken.
This thread started about whether it is correct. The term correct
has a very specific meaning in programming and that always return 1
code is correct.
Now you talk about broken.
Actually it wasn't me who brought up the term. :-)
If broken means not good, then you are right.
If broken means not correct, then you are wrong. I suspect
that broken is not very well defined.
Right. :-)
The whole idea of hashing is based on the fact that the hash code
_somehow_ represents the item to be hashed. If all items have the sam=
e
constant hash code there is no point in hashing at all. So while it
does work, it does not work as intended.
It disable the entire hashing functionality and a HashMap get
characteristics of ArrayList.
An ArrayList allows multiple occurrences of the same instance - and does =
not store key value pairs. That won't be the case with HashMap as
equals() (if properly implemented) will prevent that (albeit slowly, or
more correct: slower than with a proper implementation of hashCode()).
Also, a HashMap will degenerate more to a LinkedList via the chaining of =
a bucket's entries.
But the code should actually work.
Yes, sort of - depending on whether O(1) is a requirement or not.
Still, the idea to implement hashCode() in Object in a way to return a
constant to avoid necessity of overriding it is crazy - especially since =
you then cannot efficiently use Object as hash key - which you can today.=
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/