Suppress warning "Category is implementing a method which will also be implemented by its primary class"

Question

I was wondering how to suppress the warning:

Category is implementing a method which will also be implemented by its primary class.

I have this for a specific code category:

+ (UIFont *)systemFontOfSize:(CGFloat)fontSize { return [self aCustomFontOfSize:fontSize]; }

By method swizzling. Though I wouldn't do that -- perhaps you could make a UIFont subclass that overrides the same method instead, and call super otherwise. — Alan Zeino
– Alan Zeino, Commented Feb 24, 2012 at 1:16
Your problem isn't the warning. Your problem is that you have the same method name, which is going to lead to problems. — gnasher729
– gnasher729, Commented Apr 4, 2014 at 16:53
See Overriding methods using categories in Objective-C for reasons why you should not be overriding methods using categories, and for alternative solutions. — Senseful
– Senseful, Commented Jun 26, 2014 at 19:18
If you people know a more elegant solution to set the application-wide font, I really would like to hear it! — To1ne
– To1ne, Commented Sep 2, 2015 at 9:44

Ben Baron · Accepted Answer · 2012-09-12 19:30:19Z

Although everything bneely said is correct, it doesn't actually answer your question of how to suppress the warning.

If you have to have this code in for some reason (in my case I have HockeyKit in my project and they override a method in a UIImage category [edit: this is no longer the case]) and you need to get your project to compile, you can use #pragma statements to block the warning like so:

#pragma clang diagnostic push #pragma clang diagnostic ignored "-Wobjc-protocol-method-implementation" // do your override #pragma clang diagnostic pop

I found the information here: http://www.cocoabuilder.com/archive/xcode/313767-disable-warning-for-override-in-category.html

Thanks a lot! So, I see pragmas can suppress warnings too. :-p
Yep, and though these are LLVM specific statements, there are similar ones for GCC as well.
The warning in your test project is a linker warning, not a llvm compiler warning, hence the llvm pragma isn't doing anything. However, you'll notice that your test project still builds with "treat warnings as errors" turned on because it's a linker warning.
This really should be the accepted answer, given that it actually answers the question.
This answer should be the correct one. Anyway it has more votes than the one selected as answer.

bneely · Accepted Answer · 2013-09-22 21:12:07Z

A category allows you to add new methods to an existing class. If you want to reimplement a method that already exists in the class, you typically create a subclass instead of a category.

Apple documentation: Customizing existing classes

If the name of a method declared in a category is the same as a method in the original class, or a method in another category on the same class (or even a superclass), the behavior is undefined as to which method implementation is used at runtime.

Two methods with the exact same signature in the same class would lead to unpredictable behavior, because each caller cannot specify which implementation they want.

So, you should either use a category and provide method names that are new and unique for the class, or subclass if you want to change the behavior of an existing method in a class.

i totally agree to those ideas explained above and trying to follow them during development. but still there are could be cases, where override methods in category could be appropriate. for example, cases where multiple inheritance (like in c++) or interfaces (like in c#) could be used. just faced with that in my project and realized that overriding methods in categories are the best choice.
It can be useful when unit testing some code that has a singleton in it. Ideally, singletons should be injected into code as a protocol, allowing you to switch out the implementation. But if you already have one embedded inside your code, you can add a category of the singleton in your unit test and overide the sharedInstance and the methods you what to control to turn them into dummy objects.
Thanks @PsychoDad . I updated the link and added a quote from the documentation that's relevant to this post.
Looks good. Does Apple provide documentation on the behavior of using a category with an existing method name?
awesome, wasn't sure if I should go with category or subclass :-)

Sonny Saluja · Accepted Answer · 2012-09-24 20:33:19Z

A better alternative (see bneely's answer to why this warning is saving you from disaster) is to use method swizzling. By using method swizzling, you can replace an existing method from a category without the uncertainty of who "wins", and while preserving the ability to call through to the old method. The secret is to give the override a different method name, then swap them using runtime functions.

#import <objc/runtime.h> #import <objc/message.h> void MethodSwizzle(Class c, SEL orig, SEL new) { Method origMethod = class_getInstanceMethod(c, orig); Method newMethod = class_getInstanceMethod(c, new); if(class_addMethod(c, orig, method_getImplementation(newMethod), method_getTypeEncoding(newMethod))) class_replaceMethod(c, new, method_getImplementation(origMethod), method_getTypeEncoding(origMethod)); else method_exchangeImplementations(origMethod, newMethod); }

Then define your custom implementation:

+ (UIFont *)mySystemFontOfSize:(CGFloat)fontSize { ... }

Override the default implementation with yours:

MethodSwizzle([UIFont class], @selector(systemFontOfSize:), @selector(mySystemFontOfSize:));

Vitaliy Gervazuk · Accepted Answer · 2012-09-27 07:26:30Z

Try this in your code:

+(void)load{ EXCHANGE_METHOD(Method1, Method1Impl); }

UPDATE2: Add this macro

#import <Foundation/Foundation.h> #define EXCHANGE_METHOD(a,b) [[self class]exchangeMethod:@selector(a) withNewMethod:@selector(b)] @interface NSObject (MethodExchange) +(void)exchangeMethod:(SEL)origSel withNewMethod:(SEL)newSel; @end #import <objc/runtime.h> @implementation NSObject (MethodExchange) +(void)exchangeMethod:(SEL)origSel withNewMethod:(SEL)newSel{ Class class = [self class]; Method origMethod = class_getInstanceMethod(class, origSel); if (!origMethod){ origMethod = class_getClassMethod(class, origSel); } if (!origMethod) @throw [NSException exceptionWithName:@"Original method not found" reason:nil userInfo:nil]; Method newMethod = class_getInstanceMethod(class, newSel); if (!newMethod){ newMethod = class_getClassMethod(class, newSel); } if (!newMethod) @throw [NSException exceptionWithName:@"New method not found" reason:nil userInfo:nil]; if (origMethod==newMethod) @throw [NSException exceptionWithName:@"Methods are the same" reason:nil userInfo:nil]; method_exchangeImplementations(origMethod, newMethod); } @end

This isn't a complete example. No macro named EXCHANGE_METHOD is actually defined by the objective-c runtime.
@Vitaly stil -1. that method is not implemented for the class type. What framework are you using?
Sorry again, try this out i created file NSObject+MethodExchange
With the category on NSObject why even bother with the macro? Why not just swizzle with the 'exchangeMethod'?

Thomas Clayson · Accepted Answer · 2013-03-12 17:25:09Z

You can use method swizzling to suppress this compiler warning. Here is how I implemented method swizzling for drawing margins in a UITextField when we use a custom background with UITextBorderStyleNone:

#import <UIKit/UIKit.h> @interface UITextField (UITextFieldCatagory) +(void)load; - (CGRect)textRectForBoundsCustom:(CGRect)bounds; - (CGRect)editingRectForBoundsCustom:(CGRect)bounds; @end #import "UITextField+UITextFieldCatagory.h" #import <objc/objc-runtime.h> @implementation UITextField (UITextFieldCatagory) +(void)load { Method textRectForBounds = class_getInstanceMethod(self, @selector(textRectForBounds:)); Method textRectForBoundsCustom = class_getInstanceMethod(self, @selector(textRectForBoundsCustom:)); Method editingRectForBounds = class_getInstanceMethod(self, @selector(editingRectForBounds:)); Method editingRectForBoundsCustom = class_getInstanceMethod(self, @selector(editingRectForBoundsCustom:)); method_exchangeImplementations(textRectForBounds, textRectForBoundsCustom); method_exchangeImplementations(editingRectForBounds, editingRectForBoundsCustom); } - (CGRect)textRectForBoundsCustom:(CGRect)bounds { CGRect inset = CGRectMake(bounds.origin.x + 10, bounds.origin.y, bounds.size.width - 10, bounds.size.height); return inset; } - (CGRect)editingRectForBoundsCustom:(CGRect)bounds { CGRect inset = CGRectMake(bounds.origin.x + 10, bounds.origin.y, bounds.size.width - 10, bounds.size.height); return inset; } @end

Kris Subramanian · Accepted Answer · 2014-12-24 01:36:16Z

Over-riding properties is valid for a Class Extension (Anonymous Category), but not for a regular Category.

According to Apple Docs using a Class Extension (Anonymous Category) you can create a Private interface to a public class, such that the private interface can override the publicly exposed properties. i.e. you can change a property from readonly to readwrite.

A use case for this is when you write libraries that restrict access to public properties, while the same property needs full read write access within the library.

Apple Docs link : https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/CustomizingExistingClasses/CustomizingExistingClasses.html

Search for "Use Class Extensions to Hide Private Information".

So this technique is valid for a Class Extension, but not for a Category.

gheese · Accepted Answer · 2012-11-28 09:47:04Z

I had this problem when I implemented a delegate method in a category rather that the main class ( even though there was no main class implementation). The solution for me was to move the from the main class header file to the category header file This works fine

Leander · Accepted Answer · 2012-11-06 09:39:34Z

Categories are a good thing, but they can be abused. When writing categories your should as a principle NOT re-implement exiting methods. Doing so may cause strange side effect as you are now re-writing code that another class depends one. you could break a known class, and end up turning your debugger inside-out. It is simply bad programming.

If you need todo it, you really should subclass it.

Then the suggestion of swizzling, that is a big NO-NO-NO to me.

Swizzing it at runtime is a complete NO-NO-NO.

You want a banana to look like an orange, but only at runtime? If you want an orange, then write an orange.

Don not make a banana look and act like an orange. And worse: dont turn your banana into a secret agent who will quietly sabotaging bananas worldwide in support of oranges.

Yikes!

Swizzing at runtime may be useful for mocking behaviors in testing environment, though.
Although humorous, your answer doesn't really do more than say that all possible methods are bad. The nature of the beast is that sometimes you really can't subclass, so you are left with a category and especially if you don't own the code for the class that you are categorizing, sometimes you need to do the swizzle, and it being an undesirable method is not relevant.

Collectives™ on Stack Overflow

Suppress warning "Category is implementing a method which will also be implemented by its primary class"

8 Answers 8

16 Comments

7 Comments

Comments

4 Comments

Comments

Comments

Comments

2 Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

8 Answers 8

16 Comments

7 Comments

Comments

4 Comments

Comments

Comments

Comments

2 Comments

Linked

Related