Documentez les méthodes Obj-C héritées sans avertissements Doxygen / compilateur?

Question

Arrière-plan:

Je crée une hiérarchie de structures de données de dictionnaire composite dans Objective-C et hérite de NSMutableDictionary afin que ces classes puissent être utilisées partout où un appel NSDictionary / NSMutableDictionary est demandé. (Pour que les gens ne pensent pas que je réinvente la roue, chacun utilise un CFMutableDictionaryRef , plus une structure supplémentaire qui stocke les clés dans un ordre trié, dans l'ordre d'insertion, etc.) Conformément à la documentation d'Apple, j'ai remplacé le nécessaire NSDictionary primitives et NSMutableDictionary Primitives que toutes les autres méthodes de ces classes utilisent.

Objectif:

Etant donné que je m'efforce de documenter les API de mon framework aussi complètement que cela est raisonnable, j'aimerais le documentation de mes sous-classes personnalisées (générée par Doxygen) afin d'inclure une description des méthodes les plus courantes du dictionnaire NS (Mutable), afin que les utilisateurs ne soient pas obligés de consulter une autre page dictionnaire personnalisé hérite inchangé. De plus, la documentation doit parfois refléter les différentes fonctionnalités générées par les méthodes primitives surchargées, bien que l’implémentation de la méthode ne soit pas modifiée par rapport au dictionnaire NS (Mutable).

Problème:

Je ne reçois aucune erreur ni aucun avertissement lorsque seules les méthodes remplacées sont documentées. Si j'ajoute des commentaires qui documentent les méthodes héritées, Doxygen se plaint (et ne produira pas ladite documentation) sauf si j'ajoute un prototype de méthode au fichier d'en-tête. Si j'ajoute un prototype, le compilateur émet un avertissement indiquant que la mise en œuvre est terminée, car il n'inclut pas de définition de méthode pour la méthode déclarée. De toute évidence, il s’agit d’un cas où la méthode existe dans la classe parente, mais le compilateur ne tient pas à la mettre en œuvre car le prototype est essentiellement redéclaré dans la sous-classe.

Questions:

• Est-il possible de supprimer Xcode / gcc "définition de la méthode pour 'X' introuvable" " avertissements pour les méthodes héritées d'une classe parente?
• Est-il possible de forcer Doxygen à créer de la documentation pour une méthode pour laquelle il n’existe pas de justification? J'ai essayé d'utiliser la commande \ fn , mais j'ai obtenu les mêmes résultats.
• Est-il possible de persuader Doxygen de penser que la documentation que je rédige s’applique réellement à NSMutableDictionary, tout en la faisant apparaître pour toutes mes sous-classes personnalisées?

Modifier:

Pour autant que je sache, la réponse à la première question est à la fois oui et non. Techniquement, en utilisant le -Wno- option de protocole (ou en décochant l'avertissement "Protocoles incomplets Objective-C" dans les paramètres de construction de Xcode) n'autorise que GCC supprime les avertissements au moment de la compilation des classes qui ne le sont pas semblent mettre en œuvre toutes les méthodes de protocole. Cependant, cela masque le problème pour les classes qui n'utilisent pas vraiment toutes les méthodes nécessaires. Construire un framework qui utilise énormément les protocoles, ce n’est vraiment pas une option. Actuellement, GCC ne semble pas connaître les méthodes héritées d'une classe parent liée (non source).

Answer 1

Pour autant que je sache, vos trois questions sont les suivantes: non.

J'aimerais attirer votre attention sur le fait que la documentation Apple ne documente pas les méthodes héritées dans la documentation de la sous-classe.

De plus, NSDictionary et NSMutableDictionary ne sont pas si rares à nécessiter un rappel de leurs méthodes les plus courantes. Pour moi, un lien vers la documentation existante, comme vous l'avez déjà fait, suffit.

En ce qui concerne le comportement spécifique de ces méthodes courantes dans votre sous-classe, je voudrais simplement insérer une section dédiée dans le chapitre Description détaillée .

Quoi qu’il en soit, une solution possible consisterait à donner à la fois une déclaration et une implémentation de vos méthodes héritées. Mais c’est un peu exagéré juste pour la documentation:

- (NSArray *) allValues
{
    return [super allValues];
}