Wisdom of overriding isEqual:
Wisdom of overriding isEqual:
- Subject: Wisdom of overriding isEqual:
- From: Patrick Machielse <email@hidden>
- Date: Wed, 10 Mar 2004 13:33:03 +0100
Hi,
Recently I've been thinking about overriding the isEqual: message on
standard Cocoa classes, and I'm curious if there is any 'danger' in doing
so.
My present understanding of isEqual:
1) NSObject implements this method as:
- (BOOL)isEqual:(id)anObject
{
return self == anObject;
}
At least, this is what I expect. The documentation of NSObject won't tell
me how this NSObject Protocol message is really implemented. Strange...
2) No standard Cocoa class overrides isEqual:, at least the documentation is
silent on this.
3) isEqual: exists as a 'hook' to customize the way (mostly)
collection classes such as NSArray and NSDictionary handle objects.
If I'm way off track here, please intervene.
Lately, I've had the need to store some insances of NSURLRequest in an
NSSet, which have to be unique with respect to their contents. So I have
overriden the isEqual: message on NSURLRequest using a category. Now NSSet
(calling isEqual:) will examine the attributes of NSURLRequests to determine
if they are equal. This works fine.
My question is: won't this trip up any of the internal workings of Cocoa?
Suppose 'somewhere insyde' Cocoa relies on the default implementation of
isEqual:?
In other words, should I limit custom isEqual: implementations to my own
classes?
TIA,
Patrick,
--
Hieper Software
w: www.hieper.nl
e: email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.