"Use of unresolved Identifier" - Objekt in Swift

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

  • "Use of unresolved Identifier" - Objekt in Swift

    Hallo alle,

    ich versuche mich zurzeit in Swift einzuarbeiten. Bin gerade dabei, mir ein kleines Taschenrechner Projekt zusammenzuklicken um einmal zu probieren, wie es jenseits des Xcode Playground mit Swift aussieht.
    Ich habe meine eigene Swift Klasse "Brain.swift" erstellt (ohne großen Inhalt). Davon möchte ich nun in meinem ViewController ein Objekt erstellen (siehe Code). Es entsteht aber immer wieder folgender Error: "Use of unresolved identifier "Brain" ". Wie ist das zu erklären? Wie kann ich das Problem lösen?

    Quellcode

    1. import UIKit
    3. class ViewController: UIViewController {
    5. let obj = Brain()
    7. override func viewDidLoad() {
    8. super.viewDidLoad()
    9. // Do any additional setup after loading the view, typically from a nib.
    10. }
    11. }
    Alles anzeigen

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Nilsfrank99 ()

  • MCDan schrieb:

    Ich kenne mich mit Swift nicht aus, aber ich tippe jetzt einfach mal, dass ein import der Klasse Brain fehlt. Evtl. gibt es auch ein Problem bei der Definition der Klasse Brain.


    Am Importieren kann es zumindest nicht liegen, das ist in Swift nicht nötig. Habe jedoch meinen Fehler gefunden: Man muss, im Gegensatz von Objectiv C, noch die Grundstruktur (class Brain {}) selbst reintippen, sonst funktioniert es nicht. :) Blöder Fehler!

    Danke für deinen Denkanstoß mit der "Definition von der Klasse Brain".

    Nils

  • Ich denke UIKit muss importiert weil, keine Klasse des Projekts. Alles was du an eigenen Klassen erstellst und nicht über andere Wege in das Projekt holst ist bekannt und muss nicht importiert werden.

    @TE auch in Objective-C benötigst du die Grundstruktur einer Klasse, hier macht Xcode das aber für dich wenn du die Dateien für eine Klasse erstellst.
    Das Herz besitzt Gründe, die die Vernunft nicht kennt.

  • Ich habe mich auch mal geärgert warum man dieses blöde importieren machen muss obwohl die IDE doch gefälligst genauso gut selber in meinem Workspace suchen kann wo die benötigten Klassen sind.
    Blöd ist wenn man mal zwei Versionen der gleichen Lib in einer App braucht (Aus kompatibilitätsgründen. Hatten wir mal bei der ftlib, da war tatsächlich was nicht aufwärts kompatibel.) Da wärst Du mit Swift dann hoffnungslos verloren.

    Gruß

    Claus

    P.S. @Moon ich hatte Dir eine "Konversation" geschrieben. Keine Ahnung ob die angekommen ist
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Nilsfrank99 schrieb:

    MCDan schrieb:

    Ich kenne mich mit Swift nicht aus, aber ich tippe jetzt einfach mal, dass ein import der Klasse Brain fehlt. Evtl. gibt es auch ein Problem bei der Definition der Klasse Brain.


    Am Importieren kann es zumindest nicht liegen, das ist in Swift nicht nötig. Habe jedoch meinen Fehler gefunden: Man muss, im Gegensatz von Objectiv C, noch die Grundstruktur (class Brain {}) selbst reintippen, sonst funktioniert es nicht. :) Blöder Fehler!

    Danke für deinen Denkanstoß mit der "Definition von der Klasse Brain".

    Nils


    Du hast die Klasse Brain jetzt in deiner anderen Klasse als interne Klasse erstellt oder wie? Das ist nicht nötig! Wenn du aber eine interne Klasse haben möchtest, dann ist das auch möglich, dann musst du aber nicht mehr eine eigene Datei mit deiner nun jetzigen internen Klasse erzeugen.

  • Thallius schrieb:

    Ich habe mich auch mal geärgert warum man dieses blöde importieren machen muss obwohl die IDE doch gefälligst genauso gut selber in meinem Workspace suchen kann wo die benötigten Klassen sind.
    Blöd ist wenn man mal zwei Versionen der gleichen Lib in einer App braucht (Aus kompatibilitätsgründen. Hatten wir mal bei der ftlib, da war tatsächlich was nicht aufwärts kompatibel.) Da wärst Du mit Swift dann hoffnungslos verloren.

    Gruß

    Claus

    P.S. @Moon ich hatte Dir eine "Konversation" geschrieben. Keine Ahnung ob die angekommen ist
    Ich finde es gerade bei größeren Projekten dienlich, dass man explizit angeben muss, was man haben möchte. Das zeigt Abhängigkeiten. Zar sammeln sich bei mir dann auch zuweilen alte, nicht mehr benutzte Abhängigkeiten am Anfang einer .m-Datei. Diese pflege ich dann aber mal, was ich gerade keine Lust auf etwas anderes habe.

    "Ich nehme alles, weil das Richtige schon dabei ist", finde ich zwar bequem, aber nicht sonderlich explizit.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    "Ich nehme alles, weil das Richtige schon dabei ist", finde ich zwar bequem, aber nicht sonderlich explizit.

    Hmm. Aber ich glaube herausgelesen zu haben, dass Du jemand bist, der auch mal gutes Neues akzeptiert.
    mein halber Cent:
    1. Jede Klasse hat seinen Namen, wird sie in irgendeiner Weise laut Quellcode benötigt, wird sie importiert
    2. Eigentlich sollte so etwas fehlerlos möglich sein für Dynamisches/Late Binding gibt sicher auch entsprechende Möglichkeiten in Swift (es sei denn, alles steht zur Verfügung)
    3. Thallius Problem ist kein Problem, dafür haben die Klassen ja dann unterschiedliche Namen.

    Eigentlich spricht nur dagegen, dass wie Du sagst, die Abhängigkeiten nicht direkt sichtbar sind, aber das könnte man ja auch
    problemlos in Xcode anzeigen lassen > muss apple ja nur umsetzen. Vielleicht sogar als UML, oder einfach ausgegraut oben im Kopf der Datei, als SystemKommentar

  • entwickler schrieb:

    Amin Negm-Awad schrieb:



    3. Thallius Problem ist kein Problem, dafür haben die Klassen ja dann unterschiedliche Namen.



    Du glaubst also, dass sich bei einer Lib von einer Version zur nächsten alle Klassennamen ändern? Vielleicht in Deinem Code aber bestimmt nicht bei jedem anderen.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    Du glaubst also, dass sich bei einer Lib von einer Version zur nächsten alle Klassennamen ändern? Vielleicht in Deinem Code aber bestimmt nicht bei jedem anderen.

    Ich denke – tief im Innern – hast Du mich schon verstanden.
    Abgesehen davon sollte dein Code ja wohl über ein übergeordnetes Object deine Libs ansprechen und nicht an jeder Stelle entscheiden, ob Version1 oder Version2 zum Tragen kommt .