NSObject - respondsToSelector: behavior has changed under Leopard

Bill Bumgarner bbum at mac.com
Mon Dec 10 08:53:12 PST 2007


On Dec 10, 2007, at 6:57 AM, Florent Lacheroy wrote:
> It seems behavior of the respondsToSelector: method of NSObject has  
> changed. We have a code where the method responds "YES" under Tiger  
> and "NO" under Leopard.
>
> Please see below a little extract from our code:
>
> - we have a "fake" NSBitmapImageRep subclass. It means it's a class  
> derived from NSObject but that implements:
>
> - (Class)class
> {
> 	return [NSBitmapImageRep class];
> }

Why are you doing this?

-class really isn't intended to be overridden and is certainly not  
meant to change the class hierarchy.

It doesn't make any sense.   If you want to add a method to an  
existing class, use a category.   Or use the runtime's API for this  
purpose.

> - in a NSBitmapImageRep category we have this method:
>
> - (NSString*)sMaskNumberString
> {
> ...
> 	if([self respondsToSelector:@selector(sMaskNumber)]) {
> 		NSNumber	*sMaskNumber = [self sMaskNumber];
> ...	

That it returned YES on Tiger and that the invocation of -sMaskNumber  
worked could be construed as a bug on Tiger.   That Leopard returns NO  
is more correct.

> That means the respondsToSelector is now based on the instance's  
> class and not anymore on the methods implemented by the current  
> object in memory? Anyone can confirm? May be this new implementation  
> can bring new limits?

[self respondsToSelector:] has always been and certainly still is  
based on the instance's class.

b.bum




More information about the MacOSX-dev mailing list