Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #17857 > unrolled thread

Re: hashCode

Started by"Arne Vajhøj" <������ høj@1:261/38.remove-odu-this>
First post2012-08-13 19:38 +0000
Last post2012-08-13 19:38 +0000
Articles 1 — 1 participant

Back to article view | Back to comp.lang.java.programmer


Contents

  Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-odu-this> - 2012-08-13 19:38 +0000

#17857 — Re: hashCode

From"Arne Vajhøj" <������ høj@1:261/38.remove-odu-this>
Date2012-08-13 19:38 +0000
SubjectRe: hashCode
Message-ID<50294F03.56805.calajapr@time.synchro.net>
  To: Lew
From: "=?UTF-8?B?QXJuZSBWYWpow7hq?=" <=?utf-8?b?qxjuzsbwywpow7hq?=@1:261/38.rem
ove-nlb-this>

  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

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

[toc] | [standalone]


Back to top | Article view | comp.lang.java.programmer


csiph-web