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