Re: Wisdom of overriding isEqual:
Re: Wisdom of overriding isEqual:
- Subject: Re: Wisdom of overriding isEqual:
- From: Bill Cheeseman <email@hidden>
- Date: Wed, 10 Mar 2004 11:26:44 -0500
on 2004-03-10 7:33 AM, Patrick Machielse at email@hidden wrote:
>
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.
There is new documentation on Apple's Developer Documentation site showing
how to override -isEqual: and how to write your own -isEqualTo...: methods
in your own subclasses, with sample code. Sorry, I've forgotten the URL, but
it shouldn't be hard to find.
This documentation was a real eye-opener for me, since, as you say, the
previous documentation was less than clear on how -isEqual: fits into The
Cocoa Way.
The basic idea, as I now understand it, is that most classes implementing
some type of data, say, class MyData, should implement both an -isEqual: and
an -isEqualToMyData: method. The -isEqualToMyData: method will perform a
fast comparison taking into account special features of the MyData class and
its intended usage, and your code would use -isEqualToMyData: for efficiency
reasons whenever you can be confident that you are comparing MyData objects.
Your -isEqual: override method would make a couple of optimization calls to
deal with special cases rapidly (for example, if the parameter is nil or the
parameter's class is not MyData, the method should always return NO), and
then would call your -isEqualToMyData: method. Although this is by nature a
little slower than a direct call to -isEqualToMyData:, it has the distinct
advantage of making it possible for you to use many built-in Cocoa methods
with collection objects that might contain MyData objects.
I didn't understand this before, but this is what all those NSArray and
other method documentation references mean when they tell you that, for
example, -indexOfObject: returns a value based on object equality and adds
that "Objects are considered equal if isEqual: returns YES." Your MyData
class's custom override of the -isEqual: method will automatically be called
by NSArray's -indexOfObject: method due to the dynamic nature of
Objective-C, and your custom -isEqualToMyData: method will therefore be used
by the built-in Cocoa collection class and do exactly what you want it to
do. So you will be able to use the built-in -indexOfObject: method in your
application code instead of having to write an enumeration loop every time
you want the index of your object in an array. The built-in collection class
methods are, as I understand it, optimized so that they will be faster than
an enumeration loop, and they are certainly easier to use.
Given all of this, I think you probably have to be very careful if you write
a category to replace an existing data class's -isEqual: method. You could
break a whole lot of things in other code that depends on the way that
class's -isEqual: method works. Better to subclass the data class, override
-isEqual: in the subclass so as not to disturb the way -isEqual: works in
the base class, and write your own custom -isEqualToMyData: method specially
for MyData. If I'm right about this, this is one exception (there are many
of them) to the Cocoa bromide that you should not override classes if you
can help it.
Somebody correct me if I'm wrong about any of this.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
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.