Re: copy & isEqual nightmares
Re: copy & isEqual nightmares
- Subject: Re: copy & isEqual nightmares
- From: Preston Sumner <email@hidden>
- Date: Fri, 17 Feb 2012 22:50:34 -0700
On Feb 17, 2012, at 8:51 PM, Ken Thomases wrote:
> 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
There is also arguably some value in the explicit declaration of intent when using the class-specific equality methods; e.g., that a given bit of code expects something to be a string.
Preston
_______________________________________________
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