Ich räume meinen alten Cocoa-Code auf, um moderne Namenskonventionen zu verwenden. Es gab viele Diskussionen über Best Practices, aber ich bin mir einer Sache nicht sicher.
Ich denke darüber nach, den Kategorienmethoden einen Präfix hinzuzufügen, um die Eindeutigkeit zu gewährleisten. Es scheint allgemein akzeptiert zu sein, dass dies eine gute Idee ist, obwohl die meisten Leute sich wahrscheinlich nicht darum kümmern.
Meine Frage ist: Was ist mit einer NSDictionary Kategorie Methode wie -copyDeep , die eine tiefe Kopie macht? Die Methode wurde mit -deepCopy benannt, aber ich habe die Wörter umgekehrt, da der Analysator nach einem Präfix von "copy" sucht. Daher konnte ich vermutlich kein Präfix hinzufügen. Und das "Präfix" in der Mitte oder am Ende des Methodennamens scheint unordentlich und inkonsistent zu sein.
Ich würde mich auch für Gedanken über den Präfixstil interessieren - ich verwende derzeit DS (für Dejal Systems) für Klassenpräfixe. Aber ich weiß, dass Apple jetzt alle Zwei-Zeichen-Präfixe für sich reservieren will, also denke ich über die Verwendung von Dejal , z. Meine Klasse DSManagedObject wird in DejalManagedObject umbenannt. Um zu den Kategorien zurückzukehren, werden ihre Methoden umbenannt, um ein dejal Präfix hinzuzufügen, z. von -substringFromString: bis -dejalSubstringFromString: . Aber -dejalCopyDeep würde den Analyzer verwirren, also müsste ich vielleicht für solche Methoden inkonsistent sein und -copyDeepDejal oder -copyDeep_dejal verwenden?
Ich werde meine Kategorien und verschiedene Klassen als Open Source erneut veröffentlichen, sobald ich sie aufgeräumt habe, also wird es nützlich sein, die neuesten Konventionen zu befolgen.
Ich habe dem Apple Application Frameworks Evangelist eine E-Mail zu diesem Thema geschickt und eine Antwort erhalten, die nicht als Präfix für Kategorienmethodennamen empfohlen hat. Was mit dem Ratschlag in der zuvor verlinkten WWDC10-Session in Konflikt steht, nehme ich aber an, spiegelt Apples aktuelle Denkweise wider.
Er empfahl, sich einfach die Beta-Seed-API-Diffs anzuschauen, um Konflikte zu erkennen, was ich schon immer gemacht habe.
Ich stimme Kevin Ballard zu, Sie sollten die Namen Ihrer Kategorie-Methode voranstellen, besonders wenn Sie sie an andere verteilen. Aber Sie haben eine gültige Bedenken der Analyzer wird durch DScopy verwirrt. Der ARC-Compiler wird ebenfalls verwirrt, wenn die Definition / Implementierung von DScopy ohne ARC erfolgt und von einer anderen Klasse mit ARC (oder umgekehrt) verwendet wird.
Meine bevorzugte Lösung ist die Verwendung von "Ownership Transfer Annotations" wie:
%Vor% Sie würden verwendet werden, um das Standardverhalten der Compiler für das Lesen von Methodennamen zu überschreiben und auf sie einzugehen. Sie könnten DScopy wie folgt deklarieren: ( Diese Deklaration muss in einer Header-Datei sein, die von allen Klassen importiert wird, die diese Methode verwenden erwähnt wegen der Verknüpfung)
Quelle für NS_RETURNS... WWDC 2011 Sitzung 322 - Ziel-C Fortschritte in der Tiefe. Das Fleisch dieser Ausgabe beginnt etwa um 9:10 Uhr.
Ein Hinweis zu "Aber ich weiß, dass Apple jetzt alle zweistelligen Präfixe für sich reservieren möchte". Als persönliche Vorliebe benutze ich gerne das Zeichen _ , um das Präfix vom Namen zu trennen, es funktioniert gut für mich. Sie könnten versuchen, etwas wie:
Dies würde Ihnen drei Zeichen geben und den Namen der Methode besser lesbar machen.
Bearbeiten Als Antwort auf den im Kommentar geposteten Link.
Wie Justins Antwort auf Ihre ursprüngliche Frage jedoch sagt, kann das gebrochen werden.
In Bezug auf Attribute; Ich habe nicht vorgeschlagen, __attribute__((objc_method_family(copy))) zu verwenden. Ich habe vorgeschlagen, NS_RETURNS_RETAINED zu verwenden, was übersetzt in: __attribute__((ns_returns_retained)) . Während das erste Beispiel dort nicht kompiliert (wie er sagt) mit - (NSString *)string __attribute__((objc_method_family(copy))); kompiliert es mit - (NSString *)string; NS_RETURNS_RETAINED; einfach gut.
Offensichtlich, auch wenn die NS_RETURNS_.. vom Compiler in .m s "versteckt" sind oder auf andere Weise umgeleitet wurden und der Compiler die Direktiven nicht sehen kann, dann wird es nicht funktionieren. Aus diesem Grund würde ich vorschlagen, die Deklaration für alle Methoden, die den Analyzer / Compiler verwirren könnten, in Ihrer Hauptdatei .h (die alle anderen importiert) zu setzen, um die Wahrscheinlichkeit zu begrenzen, dass es ein Problem gibt.
Tags und Links cocoa categories