Re: [PATCH] Field position attribute handling

[Mark Wielaard]

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