Re: Using performSelector: on super

[Jonathan deWerd]

The solution I would use would be to implement a category on super's class, or rename the method (probably the best option from a design standpoint). For instance, suppose we have (stretching the objc syntax a bit)

@implementation FooClass
- (void)sayHi {
        NSLog(@"Hi");
}
@end

@implementation BarClass : FooClass
- (void)sayHi {
        NSLog(@"Hi there! I am BarClass.");
}
@end

And we have
BarClass* bar = [[BarClass alloc] init];



@implementation FooClass (MethodAliasing)
- (void)sayOriginalHi {
        static IMP originalHi = nil;

}
@end

Then [bar sayHi]; will log "Hi there! I am BarClass". If we want to call its super's method, then we can implement a category like so (assuming you don't have the code to FooClass's implementation: if you do, just change it): if (!originalHi) originalHi = [FooClass instanceMethodForSelector:@selector(sayHi:)]; originalHi(self, @selector(sayHi:) /*, additional, args, would, get, forwarded, here*/); Then you can call (or you can have NSRunLoop call) sayOriginalHi: . This little hack should be compatible with most living variants of ObjC that you are likely to encounter (it only uses Apple's official API after all). This being said, I will reiterate my suggestion that you look at your design again. The fact that you are calling super's methods outside of one of your own (or you are having the run loop do it for you) indicates that perhaps that method of super should have remained exposed, and instead of overriding it your subclass should provide an entirely new method.

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]