Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!news-out.readnews.com!transit3.readnews.com!news-out.news.tds.net!newsreading01.news.tds.net!53ab2750!not-for-mail
From: "=?UTF-8?B?QXJuZSBWYWpow7hq?=" <=?utf-8?b?qxjuzsbwywpow7hq?=@1:261/38.remove-nlb-this>
Subject: Re: hashCode
Message-ID: <502943B4.56761.calajapr@time.synchro.net>
X-Comment-To: Lew
Newsgroups: comp.lang.java.programmer
In-Reply-To: <5027FE12.56711.calajapr@time.synchro.net>
References: <5027FE12.56711.calajapr@time.synchro.net>
X-FTN-AREA: COMP.LANG.JAVA.PROGRAMMER
X-FTN-MSGID: 1:261/38 8c41b556
X-FTN-REPLY: 1:261/38 5cdc31e4
Content-Type: text/plain; charset=IBM437
Content-Transfer-Encoding: 8bit
X-Gateway: time.synchro.net [Synchronet 3.16a-Win32 NewsLink 1.98]
Lines: 61
Date: Mon, 13 Aug 2012 18:36:18 GMT
NNTP-Posting-Host: 69.21.70.65
X-Complaints-To: news@tds.net
X-Trace: newsreading01.news.tds.net 1344882978 69.21.70.65 (Mon, 13 Aug 2012 13:36:18 CDT)
NNTP-Posting-Date: Mon, 13 Aug 2012 13:36:18 CDT
Organization: tds.net
Xref: csiph.com comp.lang.java.programmer:17813

  To: Lew
From: =?UTF-8?B?QXJuZSBWYWpow7hq?= <arne@vajhoej.dk>

On 8/12/2012 2:27 PM, Lew wrote:
> Even for cases where one predicts the use will not require one or
> another of the consistency practices, it is harmless to enforce them.
>
> There are four methods a type might use to represent equality or
> identity and deviations therefrom: 'equals()' of course, and
> 'hashCode()', 'compareTo()', and 'toString()'. There may be external
> 'Comparator's on that type.
>
> All these methods on or of a type, where they exist, should be
> consistent, absent an overwhelming and sound reason not to be.

> Should you design anything that violates the consistency rule, then
> please do both Javadoc and code-comment it properly.

I agree.

(well toString is not high on my priority list for what needs to behave certain 
ways, but ...)

To make it easier to get them consistent, then I think it would be nice with 
syntactic sugar.

Like:

public class Data {
     @ValueId
     private int iv;
     @ValueId
     private String sv;
     // the rest of the class
}

which would cause the compiler to emit equals and hashCode methods that are 
test of the @ValueId fields are equal and creates a "decent" hash.

public class Data implements Comparable<Data> {
     @ValueId
     private int iv;
     @ValueId
     private String sv;
     // the rest of the class
}

could cause the compiler to output a compareTo as well.

It is invisible code, but we already got that with the default constructor.

And it will help make those methods consistent.

Of course explicit override should still be possible.

Arne

--- 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