[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Field position attribute handling
From: |
Mark Wielaard |
Subject: |
Re: [PATCH] Field position attribute handling |
Date: |
Wed, 19 Nov 2003 19:22:17 +0100 |
Hi,
On Wed, 2003-11-19 at 02:14, Dalibor Topic wrote:
> > The documentation and code don't match up now.
> > My Class Library book seems to indicate that it actually is instanceof,
> > thought in most cases your code comparing the actual Class seems more
> > correct.
>
> It's the recommended way of doing equals() if you want to avoid symmetry
> bugs. See PRAXIS 12 in Peter Haggar's Practical Java, or ยง5.1, p 119 in
> Java 2 performance and idion guide by craig lahrmann & rhett guthrie, or
> Effective Java by Joshua Bloch. Using instanceof is a bad idea because
> it allows for symmetry bugs:
I know. But that wasn't the point. If you change to code then you must
also update the documentation.
> 7 is the largest prime, that's still an iconst, iconst_7, afaik. That
> makes it take less bytecode.
>
> The rest follows recommendations from Joshua Bloch on writing good
> hashCode methods.
It would be nice if we had something about the right way (tm) of writing
the standard clone(), toString(), hashCode() and equals() in the Hackers
Guide. (hint...)
> > I couldn't find one specified, so I guess any good one will do.
> > Don't know if you need to include the field_attribute.hashCode() since
> > it will probably depend on the field_id in almost all cases.
>
> If two objects are not equal, they should have different hashCodes.
> field_attribute is checked in the equality test, so it should play a
> role in hashCode calculation as well.
Should yes, but not must. I was just wondering whether or not the
field_attribute really matters since that field and field_id indicate
the same property. Having cheap hashCode() methods is a good thing and
IMHO field_attribute does not make the hashCode() more specific. But if
you think otherwise then please do it as you have it now.
Cheers,
Mark
signature.asc
Description: This is a digitally signed message part
- [PATCH] Field position attribute handling, Dalibor Topic, 2003/11/15
- Re: [PATCH] Field position attribute handling, Mark Wielaard, 2003/11/15
- Re: [PATCH] Field position attribute handling, Dalibor Topic, 2003/11/18
- Re: [PATCH] Field position attribute handling, Mark Wielaard, 2003/11/18
- Re: [PATCH] Field position attribute handling, Dalibor Topic, 2003/11/18
- Re: [PATCH] Field position attribute handling,
Mark Wielaard <=
- Re: [PATCH] Field position attribute handling, Dalibor Topic, 2003/11/23
- Re: [PATCH] Field position attribute handling, Mark Wielaard, 2003/11/25
- The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling), Dalibor Topic, 2003/11/29
- Re: The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling), Etienne Gagnon, 2003/11/29
- 2nd attempt at Re: The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling), Dalibor Topic, 2003/11/30
- Re: 2nd attempt at Re: The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling), David Lichteblau, 2003/11/30
- Re: 2nd attempt at Re: The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling), Dalibor Topic, 2003/11/30
- Re: 2nd attempt at Re: The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling), David Lichteblau, 2003/11/30
- Re: 2nd attempt at Re: The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling), Etienne Gagnon, 2003/11/30
- 3d attempt at Re: The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling), Dalibor Topic, 2003/11/30