Re: Wisdom of overriding isEqual:
Re: Wisdom of overriding isEqual:
- Subject: Re: Wisdom of overriding isEqual:
- From: Patrick Machielse <email@hidden>
- Date: Wed, 10 Mar 2004 23:33:24 +0100
Bill,
Thank you for your lengthy reply. It seems I stumbled on a subject close to
your heart..
op 10-03-2004 17:26 schreef Bill Cheeseman
>
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.
Thanks for this pointer. It sounds very useful and I will track it down...
>
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.
[]
This makes sense, and seems to be what the documentation of isEqualToString:
tries to point out (in _1_ sentence). Except of course that it forgets to
say explicitly that isEqual: calls isEqualToString:. It all sounds very
plausible though.
If I reverse this logic, it would follow that any class sporting an
isEqualTo...: method would (likely..) override isEqual:.
Looking at the index in 'Cocoa in a Nutshell' these would be:
- NSSet
- NSArray
- NSDictionary
- NSString
- NSAttributedString
- NSData
- NSValue
- NSNumber
- NSHost
- NSDate
- NSTimeZone
This is nice, since I can then look at the documentation of isEqualTo.. for
these classes and see how equality is implemented.
But what if a class doesn't define an isEqualTo... method? Does that mean
this class doesn't override NSObject's isEqual: implementation, or does it
indeed override isEqual:, but simply _undocumented_? Either way I can't find
out how equality is defined for these objects, since NSObject's
documentation essentially says: 'isEqual's implementation defines it's own
meaning'.
>
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.
That was my gut feeling, although my straight override of isEqual: hasn't
broken anything (yet). I will change my code such that it will take the
'royal route'.
I invite anyone with more information on the implementation of isEqual: in
standard Cocoa classes to step forward :-)
Groeten,
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.