Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!news-in-01.newsfeed.easynews.com!easynews.com!easynews!news-out.news.tds.net!newsreading01.news.tds.net!53ab2750!not-for-mail From: "Patricia Shanahan" Subject: Re: hashCode Message-ID: <5027F2CB.56701.calajapr@time.synchro.net> X-Comment-To: bob smith Newsgroups: comp.lang.java.programmer In-Reply-To: <50269FCE.56638.calajapr@time.synchro.net> References: <50269FCE.56638.calajapr@time.synchro.net> X-FTN-AREA: COMP.LANG.JAVA.PROGRAMMER X-FTN-MSGID: 1:261/38 b831b036 X-FTN-REPLY: 1:261/38 225e14ea Content-Type: text/plain; charset=IBM437 Content-Transfer-Encoding: 8bit X-Gateway: time.synchro.net [Synchronet 3.16a-Win32 NewsLink 1.98] Lines: 46 Date: Sun, 12 Aug 2012 18:58:19 GMT NNTP-Posting-Host: 69.21.70.65 X-Complaints-To: news@tds.net X-Trace: newsreading01.news.tds.net 1344797899 69.21.70.65 (Sun, 12 Aug 2012 13:58:19 CDT) NNTP-Posting-Date: Sun, 12 Aug 2012 13:58:19 CDT Organization: tds.net X-Received-Bytes: 3061 Xref: csiph.com comp.lang.java.programmer:17756 To: bob smith From: Patricia Shanahan On 8/10/2012 3:22 PM, bob smith wrote: ... > 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. > I've decided to go back to this message, because I feel the key issue is the circumstances under which hashCode would need to be overridden if Object's version returned a constant, compared to the current situation. If Object's hashCode returned a constant, in practice anyone using an object as a key in a hash structure would want it overridden with one that has at least some chance of using multiple buckets. Without that property, a HashMap is an over-complicated, space-wasting cousin of a linked list. The problem with this is that the programmer who knows that Widget instances are going to be used as HashMap keys does not necessarily control the Widget implementation. The programmer writing Widget has no idea whether it will ever be used as a HashMap key, and therefore no way of knowing whether it is safe, assuming Widget inherits the Object equals, to also inherit the Object hashCode. Now compare to the current situation. The programmer implementing Widget decides whether to inherit a superclass equals or to write a Widget-specific equals. That programmer can assume the superclass has a hashCode that would be effective for a HashMap key, and only has to override hashCode if they are overriding equals. In practice, it is a long time since I've written a hashCode manually. Generally, when I decide to override equals I tell Eclipse to generate an equals/hashCode pair based on the fields that control whether two instances are equal. Overriding hashCode is no additional work given that I would be telling Eclipse to generate an equals based on those fields anyway. To me, the current situation seems "better". Patricia --- BBBS/Li6 v4.10 Dada-1 * Origin: Prism bbs (1:261/38) --- Synchronet 3.16a-Win32 NewsLink 1.98 Time Warp of the Future BBS - telnet://time.synchro.net:24