* Matthew Toseland <toad at amphibian.dyndns.org> [2008-04-05 11:22:48]:
> On Saturday 05 April 2008 04:22, Florent Daigni?re wrote: > > * Matthew Toseland <toad at amphibian.dyndns.org> [2008-04-04 19:13:51]: > > > > > On Friday 04 April 2008 06:27, nextgens at freenetproject.org wrote: > > > > Author: nextgens > > > > Date: 2008-04-04 05:27:02 +0000 (Fri, 04 Apr 2008) > > > > New Revision: 18969 > > > > > > > > Modified: > > > > trunk/freenet/src/freenet/clients/http/bookmark/BookmarkItem.java > > > > Log: > > > > implement BookmarkItem.hashCode() > > > > > > Again, two points: > > > - This will change, and therefore break containing HashSet's etc, if the > parts > > > cease to be null. Are they all essential? If they are, are they final, > > > and > > > can they be null? > > > > We must do the same checks as for equals()... If it breaks the code somehow > we should fix it. > > Of course, but I'm not sure we are doing this here: > - It is *NOT* necessary for hashCode to always return different values for > different objects. We can ignore elements with impunity. granted > - equals() is true if two BookmarkItem's have the same key and different > editions. So your code breaks equals/hashCode consistency. ok > - key and name cannot in any case be null. I'll dig up and see if I can find a reference here... but I'm almost sure the java spec says we should assume it can be. > > I've fixed the above. > > Also you haven't explained the mathematical voodoo... hashtables will > generally depend on the first few bits, which will in this case depend on the > description's hash followed by the alerts hash. Wouldn't it be better to > simply XOR all the parts together? > > In my implementation order matters with XORs it wouldn't. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080405/ab6447ef/attachment.pgp>
