Erklärung zu "@objc" gesucht

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Erklärung zu "@objc" gesucht

    Hallo Leute!

    Achtung, ich komme wieder mit einer Swift- (Anfänger-?) Frage - um auch die Hintergründe zu begreifen:

    Ich meine, verstanden zu haben, dass man über die Angabe @objc Variablen und Funktionen von Swift in Objective-C nutzbar machen kann (wie übersetzt man hier "exposed"?). Handelt es sich dabei um eigenen Code, kann ich das nachvollziehen. Nun sind mir die letzten Tage aber mindestens zwei Situationen begegnet, bei denen ich nur per try & error bzw. Compilerfehler auf dessen Verwendung kam:
    • Beim Registrieren eines Observers für Notifications wollte ich den Selektor der aufzurufenden Funktion angeben. Diese muss mit @objc definiert sein. Freundlicherweise gab es einen Hinweis beim Kompilieren.
    • Bei einem Bindung von value im Interface Builder an ein Property einer Swift-Klasse wurde dieses nicht gefunden (Fehler im key-value coding). Hier stolperte ich eher per Zufall über ein Snippet, das mich aufhorchen ließ.
    Gibt es hier irgendeine Eselbrücke / Aufstellung / anderes Indiz, das anzeigt, wann man eine Variable / Funktion entsprechend definieren muss? Ich mag nicht einfach auf Verdacht etwas in meinen Code schreiben, ohne den Grund dafür zu verstehen - und idealerweise vorher erkannt zu haben.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Eigentlich müsste die Regel ziemlich einfach sein — nur dummerweise läuft bei Objective-C ja ziemlich viel Magie im Verborgenen.
    Eins der großen Werbeversprechen von Swift ist Geschwindigkeit, und ein wichtiger Baustein dafür ist der Verzicht auf message passing, wann immer es möglich ist. Dummerweise sind etliche Features von Cocoa auf genau diesen Mechanismus angewiesen, daher würde ich im Zweifelsfall alles annotieren, was mit "der alten Welt" zusammenspielen muss.
  • @ObjC ist nichts anderes als dass die calling Convention an Object-C angepasst wird. Ist quasi ein Macro in der Kompatibilitätsschicht. Wurde damals eingeführt, dass man aus Swift auch Legacy Code ausführen konnte, ohne diesen neu zu schreiben...

    hier mal ein paar Links:
    - hackingwithswift.com/example-c…hat-is-the-objc-attribute
    - medium.com/@mahigarg/objc-in-s…20Objective%2DC%20runtime.
    - developer.apple.com/documentat…ng-objective-c-into-swift
    - developer.apple.com/documentat…runtime-features-in-swift
    - forums.swift.org/t/pitch-2-obj…mentations-in-swift/68090
    - ralfebert.de/ios/blog/swift-ob…binieren-bridging-header/
  • @Wolf, danke für die Links, insbesondere dieser war sehr hilfreich:

    developer.apple.com/documentat…runtime-features-in-swift

    Mir war zwar das "Was" halbwegs klar (nun noch etwas mehr), aber das "Wann" gab mir Rätsel auf. Entscheidend dürfte das dynamische Message-Handling sein, welches in meinen beiden Fällen für Selektoren und KVO benutzt wird. In letzterem
    Fall brauchte es sogar noch ein dynamic, um IBOutlets auch aus dem Swift-Code heraus wieder zu verändern.

    So langsam wird es klarer ... letztlich ist im Unterbau der AppKit-Frameworks noch viel Objective-C. Da fühle ich mich mit meiner App gleich weniger schlecht :D

    Danke auch an @t-no, Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • MyMattes schrieb:

    So langsam wird es klarer ... letztlich ist im Unterbau der AppKit-Frameworks noch viel Objective-C. Da fühle ich mich mit meiner App gleich weniger schlecht :D
    Tja, leider :S
    Aber langsam wird Swift und SwiftUI langsam erwachsen und bekommt langsam etwas eigenen Code spendiert. Bis dahin muss halt die alte und die neue Welt zusammen leben, und weil wir alle Faul sind, wollen wir den gleichen Code nicht mehrfach schreiben, sondern den einmal geschrieben Code mehrfach nutzen. Damit das funktioniert braucht es eine Kompatibilitätsschicht, damit man nicht zu oft selbst zu tief eingreifen muss. Eine davon ist halt @objc... bei Swift-Code brauchst den nicht mehr, aber eben bei anderen alten Codes und Funktionen..