Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #18416
| From | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: hashCode |
| References | (15 earlier) <k1ir2n$au0$1@dont-email.me> <3zc%r.5945$pd4.2658@newsfe21.iad> <k1jm6i$s5k$1@dont-email.me> <zSs%r.2724$Wh5.2588@newsfe14.iad> <k1lo7d$835$1@dont-email.me> |
| Message-ID | <k7v%r.11010$6q.8748@newsfe13.iad> (permalink) |
| Date | 2012-08-29 13:40 -0700 |
On 8/29/12 11:49 AM, Eric Sosman wrote:
> On 8/29/2012 2:06 PM, Daniel Pitts wrote:
>> On 8/28/12 5:02 PM, markspace wrote:
>>> On 8/28/2012 4:33 PM, Daniel Pitts wrote:
>>>>
>>>> interface Hasher<Type> {
>>>> int hash(Type t);
>>>
>>> Not really seeing how this is a good idea. How would you implement
>>> this?
>>>
>>>
>>>> So, that would change HashMap to take a Hasher<? super K> instance in
>>>> its constructor.
>>>
>>> This is the problem; Map (and HashMap) were desired to be spec'd as
>>> taking Object, not a subclass.
>> Actually, they are Generic, so they are not spec'd to take Object, but
>> to take a specific subtype defined at compile time. At least, now that
>> they have the addition of Generics. Pre-generics, they still had
>> Comparators which had the same behavior that I'm describing, but instead
>> of defining buckets, they define an ordering. See below.
>
> Actually, "take" is insufficiently specific. A Map<K,V>
> has a put() method with K,V parameters, and a putAll() method
> with a Map<? extends K, ? extends V> parameter. To that extent,
> Map<K,V> "takes" K.
>
> But Map<K,V> *also* has get() and remove() and containsKey()
> methods with Object parameters, not K parameters. (It also has a
> containsValue() method taking Object, not V.) So insofar as
> these methods are concerned, Map<K,V> "takes" Object.
Those are very good points. I had forgotten about the fact that get()
takes Object. The solution I come up with off the top of my head is to
update get/remove/etc... to all take the appropriate type (K or V). Yes,
this reduces some "functionality" of the class, but I doubt 99% of
programmers would care more than 1% of the time. I have used this
"feature", but only because proper typing wasn't done on an existing
legacy project.
Keep in mind, I'm talking about what Map *could* have been, not what it
could become.
>
>>>> A default Hasher<Object> could be implemented to use
>>>> System.identityHashCode and == for the common use-case.
>>>
>>>
>>> Again not seeing how you'd actually use that to put an object in a Map.
>>
>> Example usage:
>> ++++
>> // MyKeyHasher implements Hasher<MyKey>
>> Map<MyKey, MyValue> map=new HashMap<MyKey,MyValue>(new MyKeyHasher());
>>
>> map.put(myFirstKey, myFirstValue);
>> map.put(mySecondKey, mySecondValue);
>> ++++
>
> This could sort of work, but not very well. As I wrote some
> <hunt, hunt, hunt, ah!> seventeen days ago in this thread:
>
> I don't think a HashCalculator interface along
> the lines of Comparable would save the day.
>
> The difficulty is that an external Hasher would have no access to
> private fields of MyKey. That may seem a small drawback, since it
> is rare to have a contributor to an object's "value" that is not
> at the very least accessible through a getter. The Hasher might
> need to make method calls where today's built-in hashCode() just
> makes field references, but -- hey, how bad could that be?
>
> IMHO, it could be pretty bad. Take java.lang.String, for
> example: As things stand today hashCode() inspects the "value"
> of the String, and everything it uses would be accessible to a
> Hasher<String>. But hashCode() then caches the computed value
> in a private field within String to avoid recomputing it on every
> subsequent call! Could Hasher<String> do the same? How?
Nothing would prevent String from having a hashCode method which behaves
exactly as it does today. The StringHasher class would simply delegate
to the String.hashCode() method, which allows String to cache as expected.
>
> Okay, so the implementor of String perceives the problem and
> decides that String itself will provide a default Hasher<String>
> implementation. (This might be a static nested class, but it'd
> probably be more efficient to have String implement Hasher<String>
> directly, so every String is its own Hasher.) And the implementor
> of BigInteger does the same, and so does the implementor of URL,
> and of File, and of -- Hey, wait a minute! We're right back where
> we began, except with more overhead and more verbiage!
Oh no, dreaded letters in my source code. I must reduce it down to as
little as possible, even if it means having one class be responsible for
15 things.
Java is verbose, but that shouldn't determine what is good design and
what isn't. Also, as I've suggested elsethread, having a Hashable
interface (similar to Comparable) would allow Objects to define a
sensible default comparison/hashing algorithm *specific to that class*.
A class with subclasses has no sensible algorithm (unless it takes into
account the actual type before comparison). This is the use-case where
Hasher makes the most sense. The user of the objects of the class can
specify what they care about in the equality of two objects, even if
those objects are of different specific types.
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
hashCode bob smith <bob@coolfone.comze.com> - 2012-08-10 08:47 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 12:13 -0400
Re: hashCode markspace <-@.> - 2012-08-10 10:13 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 13:38 -0400
Re: hashCode rossum <rossum48@coldmail.com> - 2012-08-11 10:36 +0100
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-10 12:34 -0400
Re: hashCode bob smith <bob@coolfone.comze.com> - 2012-08-10 15:22 -0700
Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-10 15:32 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 19:30 -0400
Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 16:24 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:15 -0400
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:29 -0400
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-11 22:43 -0400
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:54 -0400
Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 21:46 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 16:53 -0400
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 17:00 -0400
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 19:27 -0400
Re: hashCode Robert Klemme <shortcutter@googlemail.com> - 2012-08-12 17:06 +0200
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 16:59 -0400
Re: hashCode Robert Klemme <shortcutter@googlemail.com> - 2012-08-13 19:17 +0200
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-19 19:42 -0400
Re: hashCode Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-08-21 10:30 +0000
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-19 19:47 -0400
Re: hashCode Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-08-21 10:43 +0000
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-27 19:04 -0400
Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-27 16:55 -0700
Re: hashCode markspace <-@.> - 2012-08-27 17:03 -0700
Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-27 17:49 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-27 21:37 -0400
Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-27 18:58 -0700
Re: hashCode markspace <-@.> - 2012-08-27 21:19 -0700
Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-28 01:06 -0700
Re: hashCode markspace <-@.> - 2012-08-28 09:19 -0700
Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-28 16:33 -0700
Re: hashCode markspace <-@.> - 2012-08-28 17:02 -0700
Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-29 11:06 -0700
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-29 14:49 -0400
Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-29 13:40 -0700
Re: hashCode Gene Wirchenko <genew@ocis.net> - 2012-08-29 18:02 -0700
Re: hashCode Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-08-31 00:52 +0200
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-30 21:43 -0400
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-30 21:52 -0400
Re: hashCode Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-08-31 04:18 +0200
Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 09:08 -0600
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-31 11:38 -0400
Re: hashCode Robert Klemme <shortcutter@googlemail.com> - 2012-08-31 17:55 +0200
Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 09:56 -0600
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-31 14:32 -0400
Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 14:38 -0600
Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-31 15:33 -0700
Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 16:41 -0600
Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-31 16:26 -0700
Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-09-02 11:54 -0600
Re: hashCode Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-09-03 00:47 +0200
Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-09-03 21:44 -0600
Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 09:08 -0600
Re: hashCode Robert Klemme <shortcutter@googlemail.com> - 2012-08-31 17:58 +0200
Re: hashCode markspace <-@.> - 2012-08-29 11:51 -0700
Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-29 13:28 -0700
Re: hashCode markspace <-@.> - 2012-08-29 16:05 -0700
Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-29 16:23 -0700
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-29 20:56 -0400
Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-30 11:19 +0200
Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-30 10:03 -0700
Re: hashCode Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-08-30 18:34 +0000
Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-30 08:11 -0600
Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-30 10:06 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-30 19:16 -0400
Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-28 13:58 -0700
Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-28 13:56 -0700
Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-28 14:07 -0700
Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-28 14:38 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-27 21:12 -0400
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-11 07:58 -0400
Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 16:29 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:16 -0400
Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-12 03:46 -0700
Re: hashCode Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-08-12 12:23 -0400
Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-12 09:40 -0700
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-12 13:59 -0400
Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-12 11:17 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 17:02 -0400
Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-12 19:03 +0200
Re: hashCode Roedy Green <see_website@mindprod.com.invalid> - 2012-08-10 12:17 -0700
Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-10 12:45 -0700
Re: hashCode Roedy Green <see_website@mindprod.com.invalid> - 2012-08-11 04:54 -0700
Re: hashCode Joerg Meier <joergmmeier@arcor.de> - 2012-08-11 18:25 +0200
Re: hashCode Mike Winter <usenet@michael-winter.me.invalid> - 2012-08-11 18:53 +0100
Re: hashCode Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-08-11 09:56 -0700
Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-11 18:58 +0200
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:40 -0400
Re: hashCode rossum <rossum48@coldmail.com> - 2012-08-11 18:47 +0100
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 19:25 -0400
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-11 08:00 -0400
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 09:49 -0400
Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-11 15:33 +0200
Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-11 15:34 +0200
Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 16:34 -0700
Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 16:37 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:19 -0400
Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 21:48 -0700
Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-12 12:08 +0200
Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-12 12:18 +0200
Re: hashCode Lew <noone@lewscanon.com> - 2012-08-12 11:27 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 17:11 -0400
csiph-web