Ayende @ Rahienhttp://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Ayende Rahien commented on Relying on hash code implementation is BAD – part IIJames, That is actually something that you _should_ be worried about in a mixed 32 & 64 bits env. Most distributed caches does the naive thing and use GetHashCode to get the hashcode for the key lookup. Granted, there aren't that many mixed bits mode, but it is important to know http://ayende.com/3981/relying-on-hash-code-implementation-is-bad-part-ii#comment7http://ayende.com/3981/relying-on-hash-code-implementation-is-bad-part-ii#comment7Tue, 28 Apr 2009 17:05:59 GMTJames commented on Relying on hash code implementation is BAD – part IIString.GetHashCode() returns different values when running in a 32-bit or 64-bit image. Now, if you serialized the value somewhere in a file format... Yes, it happened. No comments please ;) http://ayende.com/3981/relying-on-hash-code-implementation-is-bad-part-ii#comment6http://ayende.com/3981/relying-on-hash-code-implementation-is-bad-part-ii#comment6Tue, 28 Apr 2009 12:16:33 GMTNik commented on Relying on hash code implementation is BAD – part IIAgreed, it doesn't read well that alerts["SELECT N+1"] means get the alert with the title "SELECT N+1" especially with the one below it "alerts["Too many database calls per session"]" which looks like your using the [] to set a message not select a title. Though in my eyes, it's more of a case of bad titling. :P But then using more code like titles to reference a full alert would probably read just as cryptic. http://ayende.com/3981/relying-on-hash-code-implementation-is-bad-part-ii#comment5http://ayende.com/3981/relying-on-hash-code-implementation-is-bad-part-ii#comment5Tue, 28 Apr 2009 08:50:31 GMTAyende Rahien commented on Relying on hash code implementation is BAD – part IIBill, My main concerns arereadability and sensability http://ayende.com/3981/relying-on-hash-code-implementation-is-bad-part-ii#comment4http://ayende.com/3981/relying-on-hash-code-implementation-is-bad-part-ii#comment4Tue, 28 Apr 2009 04:31:25 GMTBill Pierce commented on Relying on hash code implementation is BAD – part IIIt is not obvious from your posts, excluding the readability of the code, what the non obvious side affects are of using GetHashCode in this way. Can you enlighten me? http://ayende.com/3981/relying-on-hash-code-implementation-is-bad-part-ii#comment3http://ayende.com/3981/relying-on-hash-code-implementation-is-bad-part-ii#comment3Mon, 27 Apr 2009 20:07:50 GMTAyende Rahien commented on Relying on hash code implementation is BAD – part IIa, Not really. If you don't have that, you can't write hash table or dictionary. http://ayende.com/3981/relying-on-hash-code-implementation-is-bad-part-ii#comment2http://ayende.com/3981/relying-on-hash-code-implementation-is-bad-part-ii#comment2Mon, 27 Apr 2009 15:19:18 GMTa commented on Relying on hash code implementation is BAD – part IIbtw, this is not relying on a particular hash code but on the fact that gethc and equals are properly implemented, so that: a.eq(b) => a.gethc() == b.gethc() a.gethc() != b.gethc() => !a.eq(b) and that eq and gethc are taking into account all relevant fields. however an "action" kind of object (without knowing exactly what your statementaction does) is probably not the right kind of hash code provider. gethc should only be implemented for value object imo. i also think it is a mistake in the framework design that every object has equals and gehashcode methods. that is clearly something that _not_ every object can and should support. http://ayende.com/3981/relying-on-hash-code-implementation-is-bad-part-ii#comment1http://ayende.com/3981/relying-on-hash-code-implementation-is-bad-part-ii#comment1Mon, 27 Apr 2009 15:14:17 GMT