Received: by 10.68.141.225 with SMTP id rr1mr2631639pbb.2.1346114964618; Mon, 27 Aug 2012 17:49:24 -0700 (PDT) Received: by 10.68.218.226 with SMTP id pj2mr3106282pbc.19.1346114964601; Mon, 27 Aug 2012 17:49:24 -0700 (PDT) Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.linkpendium.com!news.linkpendium.com!news.snarked.org!newsfeed.news.ucla.edu!usenet.stanford.edu!4no21396756pbn.1!news-out.google.com!a8ni39172319pbd.1!nntp.google.com!q4no7487417pbi.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.java.programmer Date: Mon, 27 Aug 2012 17:49:24 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.28.149.29; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T NNTP-Posting-Host: 69.28.149.29 References: <563f186a-edb3-4311-ae48-3af7decfce2c@googlegroups.com> <6ac6c252-c370-4f74-b29d-ce5368019977@googlegroups.com> <502598d0$0$287$14726298@news.sunsite.dk> <5028191b$0$290$14726298@news.sunsite.dk> <50317b03$0$281$14726298@news.sunsite.dk> <503bfd0f$0$282$14726298@news.sunsite.dk> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <1de9fc01-e90f-4492-adb9-9138c6a1d291@googlegroups.com> Subject: Re: hashCode From: Lew Injection-Date: Tue, 28 Aug 2012 00:49:24 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: csiph.com comp.lang.java.programmer:18339 On Monday, August 27, 2012 5:03:37 PM UTC-7, markspace wrote: > Daniel Pitts wrote: >> I find it somewhat disappointing that there are Comparable/Comparator >> interfaces, but no Hashable/Hasher interfaces. > > I think -- I'm not sure, but I believe -- the the ability to hash > something into a hash table (a symbol table, in some terminologies) was > considered so important and so fundamental to so many algorithms that it > was deemed intrinsic to the system. And therefore mandated for all objects. Right or wrong, that's plausible. And a separate Hasher interface would be kludgey. > For example, in C, one can always hash based on memory address. In Java > we don't have that option, so hashCode() takes the place of the > intrinsic property of an address. That really makes sense. We have a nearly unique code for every object, and in practical terms one is vanishingly unlikely to get duplicate identity hashes within any given run. > Whereas the ability to sort or order objects was recognized as not being > intrinsic to all objects, so it was separated out. Sorting a list, or > ordering a tree, isn't something you can always do by default. > > Just my two nickels here, and of course I'm guessing as to why > hashcode() is included in Object and not an interface. So to cap this topic, we have a default identity hash in the 'Object#hashCode()' implementation that does a good job of distributing things in 'HashMap' and the like, and matches the semantics of the default identity 'equals()'. The OP's question as to whether one should substitute the degenerate hash gets a resounding "NO!" One overrides 'hashCode()' for consistency with 'equals()' exactly when the latter is overridden. If the type in question implements 'Comparable' then the 'compareTo()' method likewise should match, as should 'toString()' (in a somewhat looser sense of "match", perhaps, but not too loose). All four methods speak to the semantics of sameness for the type in question, and should be consistent with each other. -- Lew