When you are right you are right. Thanks for reminding me the Hash logic. Forgot about the collisions :((( Silly me. Thanks again. (btw, cormen is quite a big book that lies in my library, collecting the dust) :))))
Then keep up the fight for the changes, Alex -----Original Message----- From: Shevek [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 04, 2004 4:37 PM To: Apache Torque Users List Subject: RE: hashCode/equals contract broken in BaseObject On Tue, 4 May 2004, Dovlecel Alexandru Ovidiu wrote: > I think the approach that you provide will not work, because the XOR > operation will produce overlapping hashkeys. For example the following two > couples will provide the same key, even though they are different objects: > > (class.hashCode in binary, pk.hashCode in binary) --> object.hashCode > > (1110, 0001) --> 1111 > (1010, 0101) --> 1111 That doesn't matter, as long as equals() discriminates correctly between the objects. Collisions are a natural feature of any hash algorithm, by the very fact that a hash function is lossy. Equals must look like: (getClass() == ob.getClass()) && (key == ob.getKey()) Right now, all the hashcodes are likely to be equal anyway since they all just use the primary keys, so in fact the situation is currently worse than you suggest. > So an object of type identified by 1110 (14) that has the pk.hashCOde equal > to 1 > WILL BE EQUAL > with an object of type identified by 1010 (10) that has the pk.hashcode > equal to 5 No. They just have the same hashcode. They are not equal. That is why there are separate hashCode() and equals() methods in Java. The equals method must ONLY return true if the objects really are equal. hashCode() can return whatever it likes, but performance will improve if collisions are reduced. It's fairly common to stress test hash implementations by making hashCode() always return zero. However, equals() must always work. To be honest, as long as BaseObject::equals() gets fixed, hashCode() can stay as it is (but performance will still suck). > If I am wrong (I am not too good with the binary operations and the binary > format) pls correct me... I suggest Cormen, Rivest, et al. Algorithms, 2nd ed for a basic illustrative description of hashing. Knuth for the more complete description. S. > Enjoy, > Alex > > > > > -----Original Message----- > From: Shevek [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 04, 2004 4:22 PM > To: Apache Torque Users List > Subject: RE: hashCode/equals contract broken in BaseObject > > > On Tue, 4 May 2004, Dovlecel Alexandru Ovidiu wrote: > > > You can use torque objects as hash keys with one condition: > > > > all the keys in the hashtable must be instances of the same torque class. > > Then you will not have any inconsistency. > > I know this. However, this is in violation of the equals() contract and > causes much breakage. equals() should return true if and only if the > objects are equal. I have a requirement to mix class types. I have > suggested a fix for this: use > > getClass().hashCode() ^ key.hashCode() > > instead of > > key.hashCode() > > Then the whole world will work as intended again. > > S. > > > -----Original Message----- > > From: Shevek [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, May 04, 2004 4:07 PM > > To: Apache Torque Users List > > Subject: hashCode/equals contract broken in BaseObject > > > > > > hashCode and equals in BaseObject rely only on the primary key. This > > breaks horribly (violates the general contract of hashCode()/equals()) if > > you compare two objects of different classes. > > > > It MUST compare ob.getClass() as well as ob.getPrimaryKey() and include > > ob.getClass().hashCode() in its hashCode() [by xor?] [or something > > equivalent]. > > > > No doubt the reason for this violation is noted in the FAQ, but it seems > > worth noting as a serious bug since it means I can't use Torque objects as > > > hash keys. > > > > S. > > > > > > -- Shevek http://www.anarres.org/ I am the Borg. http://www.gothnicity.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
