2017-10-19 3 views
2

HintergrundObjective-C: erzwingen Kompilierungsfehler auf NULL-Zulässigkeit Anmerkung Verletzung

Wir öffentliche dynamische iOS/macOS Rahmen entwickelt haben. Das Framework ist in Objective-C geschrieben, aber es ist voll kompatibel mit Swift.

Vor kurzem haben wir NULL-Zulässigkeit Anmerkung für einen unserer öffentlichen API-Methoden geändert:

von

- (void)setServer:(nullable ABCLocation *)location; 

zu

- (void)setServer:(nonnull ABCLocation *)location; 

, so Entwickler benötigen würde [ABCLocation default] Instanz und Pass erstellen es zu neuer API.

Frage

nun uns betrifft, wie Entwickler zu erzwingen/notify ihre bestanden Code um unsere neue API zu ändern?

Wenn die API mit Swift verwendet wird, scheint es die Nullität recht gut zu behandeln, indem es einen Fehler auslöst.

Objective-C, erzeugt nur eine Warnung aber, wenn nil übergeben wird, Xcode tut nichts, wenn die Entwickler eine der Methode nullable Grundstück vorbeiführt.

Wie erzwingen wir Entwickler, ihre API zu ändern? Was sind die üblichen Praktiken hier?

UPD:

Wir verteilen den Rahmen als binäres, gebaut mit Veröffentlichung Konfiguration, wo Behauptungen ausgeschaltet sind.

UPD # 2:

Bisher haben wir die Realität akzeptiert haben, wenn unsere API von Objective-C verwendet wird. Wir haben jedoch ein "fail safe" -Verhalten implementiert: Wenn nil übergeben wird, erstellt die Methode intern [ABCLocation default] Instanz und übergibt sie implizit.

+1

"Xcode tut nichts, wenn Entwickler der Methode eine Nullable-Eigenschaft übergibt." Etwas anderes ist falsch, Sie sollten Warnungen erhalten, wenn dies tatsächlich der Fall war. – Mike

Antwort

1

Das Generieren einer Warnung, wenn die Annotation nicht erreicht wird, ist eine gute Vorgehensweise. Änderungen wie nullable ->nonnull in APIs sind nicht möglich.

+0

Könntest du bitte etwas bewegen? "Änderungen wie" nullable "->' nonnull' in APIs zu machen ist keine [gute Praxis] "? –

+0

Ich meinte nur, dass das Brechen von Änderungen von zweifelhafter Nützlichkeit in API ist keine gute Idee im Allgemeinen –

+0

Einverstanden. Danke für deine Hilfe! Wie ich in ** UPD # 2 ** erwähnt habe, hatten wir ein "ausfallsicheres" Verhalten hinzugefügt, um die Dinge nicht zu stören. Wenn Sie Ihre Antwort als akzeptiert markieren, korreliert sie mit der endgültigen Entscheidung, die ich getroffen habe. –

1

Wenn Sie den Compiler nicht dazu bringen, einen Fehler zu erzwingen (wie in Ihrer Instanz), ist es üblich, einen Laufzeitfehler auszulösen. Etwas wie:

- (void)setServer:(nonnull ABCLocation *)location  
{ 
    if (!location) { 
     NSAssert(NO, @"Location must not be nil"); 
    } 

Es ist nicht ideal, aber die Kombination einer Compiler-Warnung, wenn nil übergeben wird und ein Laufzeitfehler auf Missbrauch geworfen sollte ziemlich klar Entwickler sein falsch mit Ihrem Rahmen.

+0

Wir verteilen das Framework in einer binären Form mit einer * Release * -Konfiguration, in der Assertions deaktiviert sind. Vergiss es zu erwähnen. Ich habe die Frage aktualisiert. –