I see your point, and I have been writing Obj-C code since 1991 and
don't recall ever having written a hash method, and it's never bitten
me before.
...but I believe Kyle's point is very valid. The documentation is very
explicitly saying that you should implement it, so if you don't then
you can't complain when they change their implementation to use the
hash value and all your stuff breaks. And of course, in many cases
using a hash value would be a very good performance optimization.
But having said that, if they did change the implementation of the
collection classes to use the hash values, then there would be a
massive amount of code broken.
For me, I'm quite happy to just add a method:
- (NSUInteger)hash {
return 0; // Force the caller to call the isEqual: method to actually
determine equality.
}
to all my classes that implement isEqual: and thus apply by the
(seemingly unenforced) law.
Gideon
On 20/08/2009, at 11:19 AM, Seth Willits wrote:
I probably shouldn't admit this, but I've yet to override hash and
have yet to notice any problems. The docs say I should, so I realize
I likely should, but I would really like a concrete reason to do so.
I've never called hash, nor seen it ever called by anyone else's
code. I assume the frameworks call it from somewhere, but where?
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
