Re: copy & isEqual nightmares
Re: copy & isEqual nightmares
- Subject: Re: copy & isEqual nightmares
- From: Ken Thomases <email@hidden>
- Date: Fri, 17 Feb 2012 21:51:57 -0600
On Feb 17, 2012, at 2:33 PM, Ben Kennedy wrote:
> On 16 Feb 2012, at 3:54 pm, Ken Thomases wrote:
>
>> In other words, you're being silly. It's clear to everyone that -[NSString isEqual:] must have semantics built on -[NSString isEqualToString:], which is clearly documented.
>
> What value does NSString's isEqualToString: bring to the table over its implementation of isEqual? Is it just a matter of foregoing an 'if ([obj isKindOfClass:[NSString class])' construct at the front end? Put another way, why does NSString provide isEqualToString: as a distinct method?
The -[NSString isEqualToString:] docs say, "When you know both objects are strings, this method is a faster way to check equality than isEqual:."
In truth, though, the difference is probably slight. -isEqual: checks if the other object pointer is nil, checks the class, and invokes -isEqualToString:. So, there's a savings, but it's pretty trivial. Back in the day, though, when CPUs were slower and the Objective-C runtime was less well optimized, it might have been significant. At this point, of course, it has to be maintained for backward compatibility.
There's a minor type-safety advantage, too, I suppose. If you pass a pointer whose static type is not NSString* or a subclass to -isEqualToString:, the compiler will complain, possibly alerting you to a mistake. Similarly, when implementing a -isEqualTo<Type>: method in one of your own classes, the type of the argument will be the specific type instead of "id", so you can get better checking of your implementation.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden