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
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
