Proble

Ich habe kürzlich eine Warnung in einem Drittanbieter-Dienstprogramm (WEPopover) in folgendem Code festgestellt:

_effectivePopoverContentSize = _contentViewController.contentSizeForViewInPopover;

Dies erzeugte die folgende Warnung:

warning: 'contentSizeForViewInPopover' is deprecated: first deprecated in iOS 7.0 - Use UIViewController.preferredContentSize instead. [-Wdeprecated-declarations]
            _effectivePopoverContentSize = _contentViewController.contentSizeForViewInPopover;

Eine vorübergehende Lösung für dieses Problem in Objective-C besteht darin, die Pragma-Clang-Diagnose zu verwenden, um den Fehler zu beseitigen (ich überlasse es dem Autor des Codes, eine echte Lösung zu finden). Also habe ich den Code so überarbeitet:

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wdeprecated-declarations"
            _effectivePopoverContentSize = _contentViewController.contentSizeForViewInPopover;

#pragma clang diagnostic pop

Frag

Was funktioniert prima, aber das hat mich zu der Überlegung veranlasst, was zu tun ist, wenn es eine Alternative gibt, bei der eine ähnliche falsch-positive Warnung beim Codieren in Swift stummgeschaltet werden muss?

Überlegungen

Ich habe die Tatsache beobachtet, dass ich solche Warnungen projektweit deaktivieren kann (mithilfe der Xcode-Einstellungen), aber ich möchte das Inline-Problem wie oben erwähnt berücksichtigen. Ich habe auch darüber nachgedacht, ein #define in eine .bridging-header.h-Datei in meinem Swift-Projekt einzufügen und irgendwie davon Gebrauch zu machen. Ich bin jedoch auf der Suche nach einer Swift-spezifischen Lösung für dieses Problem. Ich verstehe, dass Pragma nicht mehr verfügbar ist und ich habe SO gesucht und ähnliche, aber keine doppelten Fragen gefunden.

AKTUALISIERTE AUFLÖSUNG: Swift 2.0

Die angegebene Antwort behandelt meine Besorgnis über Inline-Warnungen. Mit dem Availability-Befehl sollten solche Probleme vermieden werden können, da beim Kompilieren eine Warnung ausgegeben wird.

Apples Swift-Buch besagt definitiv:

“Sie verwenden eine Verfügbarkeitsbedingung in einer if- oder guard-Anweisung, um einen Codeblock bedingt auszuführen, abhängig davon, ob die zu verwendenden APIs zur Laufzeit verfügbar sind. Der Compiler verwendet die Informationen aus der Verfügbarkeitsbedingung, wenn er überprüft, ob die APIs in diesem Codeblock verfügbar sind.

 if #available(iOS 9, OSX 10.10, *) {
 // Use iOS 9 APIs on iOS, and use OS X v10.10 APIs on OS X 
 } else {
 // Fall back to earlier iOS and OS X APIs 
 }

”

Auszug aus: Apple Inc. „Die schnelle Programmiersprache (Swift 2 Prerelease).“ IBooks.https: //itun.es/us/k5SW7. ”

One könnte sogar die Guard-Anweisung in Verbindung mit der Verfügbarkeit verwenden, um den Gültigkeitsbereich vorzeitig zu verlassen, sofern die verfügbaren Bedingungen nicht erfüllt sind.

guard #available(iOS 8.0, OSX 10.10, *) else { return }

Auszug aus: Apple Inc. „Verwenden von Swift mit Cocoa und Objective-C (Swift 2-Vorabversion).“ IBooks.https: //itun.es/us/utTW7.

Darüber hinaus werden meine Bedenken hinsichtlich der Handhabung von Makros wie folgt behandelt. Wenn man bedenkt, dass Swift keinen Präprozessor hat, scheinen diese Tools der richtige Weg zu sein.

“Einfache Makros

Wo Sie normalerweise mit der Direktive #define eine Primitivkonstante in C und Objective-C definiert haben, verwenden Sie in Swift stattdessen eine globale Konstante. Beispielsweise kann die Konstantendefinition #define FADE_ANIMATION_DURATION 0.35 mit let FADE_ANIMATION_DURATION = 0.35 besser in Swift ausgedrückt werden. Da einfache, konstantenähnliche Makros direkt auf globale Variablen von Swift abgebildet werden, importiert der Compiler automatisch einfache Makros, die in C- und Objective-C-Quelldateien definiert sind. “

Auszug aus: Apple Inc. „Verwenden von Swift mit Cocoa und Objective-C (Swift 2-Vorabversion).“ IBooks.https: //itun.es/us/utTW7.

“Komplexe Makros

Complex-Makros werden in C und Objective-C verwendet, haben jedoch kein Gegenstück in Swift. Komplexe Makros sind Makros, die keine Konstanten definieren, einschließlich funktionsähnlicher Makros in Klammern. In C und Objective-C verwenden Sie komplexe Makros, um Einschränkungen bei der Typprüfung zu vermeiden oder das erneute Eingeben großer Mengen von Code aus dem Boilerplate-Code zu vermeiden. Makros können jedoch das Debuggen und Refactoring erschweren. In Swift können Sie Funktionen und Generika verwenden, um dieselben Ergebnisse ohne Kompromisse zu erzielen. Daher werden die "komplexen Makros, die sich in C- und Objective-C-Quelldateien befinden, Ihrem Swift-Code nicht zur Verfügung gestellt."

Auszug aus: Apple Inc. „Verwenden von Swift mit Cocoa und Objective-C (Swift 2-Vorabversion).“ IBooks.https: //itun.es/us/utTW7.

Der Entwickler der API kann die Verfügbarkeit von Funktionen in Swift folgendermaßen markieren:

available(iOS 8.0, OSX 10.10, *)
func useShinyNewFeature() {
    // ...
}

Auszug aus: Apple Inc. „Verwenden von Swift mit Cocoa und Objective-C (Swift 2-Vorabversion).“ IBooks.https: //itun.es/us/utTW7.

Das Hinzufügen dieser Markierungen zu Funktionen, die für Swift neu geschrieben wurden, scheint eine gute Möglichkeit zu sein, die Abwärtskompatibilität für Frameworks aufrechtzuerhalten. Die Kombination aus Wache und verfügbarem Code ermöglicht es Benutzern dieser Frameworks, die Logik nach Bedarf anzupassen. Das beruhigt mich im Umgang mit Inline-Warnungen, API-Fallbacks und Makros im Allgemeinen.