views:

356

answers:

1

Background:

I'm creating a hierarchy of composite dictionary data structures in Objective-C, and am inheriting from NSMutableDictionary so these classes can be used everywhere an NSDictionary/NSMutableDictionary is called for. (Just so people don't think I'm reinventing the wheel, each one uses a CFMutableDictionaryRef, plus some additional structure that stores the keys in sorted order, insertion order, etc.) In keeping with Apple's documentation, I've overridden the necessary NSDictionary primitives and NSMutableDictionary primitives which all the other methods in those classes use.

Goal:

Since I strive to document the APIs for my framework as completely as is reasonable, I would like the documentation for my custom subclasses (generated by Doxygen) to include descriptions of the most common methods of NS(Mutable)Dictionary, so users don't have to look at another page just to the methods that a particular custom dictionary inherits unchanged. In addition, sometimes the documentation must reflect the different functionality caused by the overridden primitive methods, although the method implementation is unchanged from NS(Mutable)Dictionary.

Problem:

I get no errors/warnings when only the overridden methods are documented. If I add comments that document inherited methods, Doxygen complains (and won't produce said documentation) unless I add a method prototype to the header file. If I add a prototype, the compiler issues a warning that the implementation is complete, since it doesn't include a method definition for the declared method. Obviously, this is a case where the method exists in the parent class, but the compiler is being a stickler about implementing it since the prototype is essentially redeclared in the subclass.

Questions:

  • Is it possible to make Xcode/gcc suppress "method definition for 'X' not found" warnings for methods inherited from a parent class?
  • Is it possible to force Doxygen to create documentation for a method for which no delaration exists? I tried to use the \fn command, but got the same results.
  • Is is possible to fool Doxygen into thinking that the documentation I write actually applies to NSMutableDictionary, yet have it appear for all my custom subclasses?

Edit:

So far as I can tell, the answer to the first question is both yes and no. Technically, using the -Wno-protocol option (or unchecking the "Incomplete Objective-C Protocols" warning in the Xcode build settings) does cause GCC to suppress compile-time warnings about classes that do not appear to implement all protocol methods. However, this masks the problem for classes that really don't implement all the necessary methods. For building a framework that makes heave use of protocols, that's really not an option. Currently, GCC doesn't seem to know about methods inherited from a linked (non-source) parent class.

+2  A: 

As far as I know, answer to your three questions is: no.

I would like to draw your attention to the fact that Apple documentation does not document inherited methods in subclass documentation.

Moreover NSDictionary and NSMutableDictionary are not so uncommon to need a reminder of their most common methods. For me a link to existing documentation, as you already have, is sufficient.

About your point of specific behaviour of these common methods on your subclass, I would just insert a dedicated section in the Detailed Description chapter.

Anyway, a possible workaround would be to give both a declaration and an implementation of your inherited methods. But it is a bit overkill just for documentation purpose:

- (NSArray *) allValues
{
    return [super allValues];
}
mouviciel
No need to draw my attention to the way Apple's docs do it, I'm quite aware of that. However, their documentation is created via HeaderDoc and hand-tweaking. Also, classes don't have links to their subclasses, so navigation isn't as easy as Doxygen or Javadoc. However, you make an excellent point about expecting users to know where to find docs for any other methods. Accordingly, I've stripped the extra method documentation from the header and the warnings are gone. Documentation is only included when a method is overridden and changes the inherited behavior. Thanks for your answer!
Quinn Taylor