7

I am intentionally using a category to override a method that I know is already implemented on a primary class. I know this is typically a sign of weak design-- please, no lectures-- but I can't subclass cleanly in this case. I know swizzling may also be an option.

But for right now, how can I suppress this warning? llvm throws a compiler warning that I can disable (diagnostic ignored "-Wobjc-protocol-method-implementation"). But then the linker also complains.

This asks a similar question but was looking for a different answer. How can I tell the linker not to complain?

Thanks.

Community
  • 1
  • 1
Ben Zotto
  • 70,108
  • 23
  • 141
  • 204
  • You may not be able to suppress the warning as, really, it should be a hard error. – bbum Jan 19 '13 at 16:56
  • @bbum: Thanks. Does this statement sound right to you? "This is a hard warning because it's important to prevent people from doing this by *accident* and thus subtly screwing up something. Categories are there to globally *augment* functionality, subclasses are there to extend or in some cases *override* functionality. If one must override without subclassing, swizzling is the more intentional and less (for some definition of "less") fragile way of doing it." – Ben Zotto Jan 20 '13 at 16:50
  • I'd say swizzling is precise, but not that much less fragile in that you still are assuming your implementation is fully compatible with the internal implementation details of the original (even if you do call the original, there is still a big set of assumptions being made). – bbum Jan 20 '13 at 20:59
  • possible duplicate of [Suppress warning "Category is implementing a method which will also be implemented by its primary class"](http://stackoverflow.com/questions/9424004/suppress-warning-category-is-implementing-a-method-which-will-also-be-implement) – CodaFi May 22 '13 at 20:05
  • 2
    Not a dupe, really, since the question is about the **linker** and not the compiler. The other question is not specific to the compiler, but most of the answers are. You can't solve it with pragmas or `-W`. – paulmelnikow Jun 16 '13 at 02:00
  • @bbum, since you would advocate the paternalistic (cough) policy of being forbidden to use this mechanism entirely via linker error, how would you go about overriding methods for eg testing frameworks? Say, I want to have differing implementations in spec and app for abstract methods defined on the base class. If there's a better approach that isn't agonizing or clumsy, I'd love to use it, but this hardly seems so dire; the implementation details are controlled internally, swizzling counts as 'pretty damn clumsy'.... – tooluser Oct 03 '13 at 17:08
  • This is a duplicate of [suppress instance method override linker warning framework xcode](http://stackoverflow.com/questions/11829512/suppress-instance-method-override-linker-warning-framework-xcode) . There are a couple of different linker flag approaches to silencing it, though as bbum mentioned it'd be best to use neither for production code. Testing frameworks though, have at it. – Carl Lindberg Dec 03 '13 at 23:53

1 Answers1

1

Unfortunately, there's no good answer.

The only linker-based solution is to pass -Wl,-w at link time; that is, tell Clang to pass the -w option through to the linker. This will suppress all linker warnings, potentially including ones you'd still like to see.

A higher-level workaround is to pipe the linker's output through grep -v. The details of that solution would tend to depend heavily on your shell and your build system.

Quuxplusone
  • 23,928
  • 8
  • 94
  • 159