Optional<AnyObject> Typ bekommen

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

  • prettygirl schrieb:

    In der plist-Datei sind Einstellungen gespeichert, aber es stört mich einfach, wenn man da beliebig zahlen schreiben kann . es funktioniert zwar auch mit den Zahlen aber mich stört das so einfach
    Fehler innerhalb einer Datei kannst du nie vermeiden. Die Konsistenz der Daten können allenfalls die Programme sicherstellen, die die Dateien schreiben. Vielleicht solltest du für deine Anforderungen auch ein applikationsspezifisches Format entwickeln.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    prettygirl schrieb:

    In der plist-Datei sind Einstellungen gespeichert, aber es stört mich einfach, wenn man da beliebig zahlen schreiben kann . es funktioniert zwar auch mit den Zahlen aber mich stört das so einfach
    Fehler innerhalb einer Datei kannst du nie vermeiden. Die Konsistenz der Daten können allenfalls die Programme sicherstellen, die die Dateien schreiben. Vielleicht solltest du für deine Anforderungen auch ein applikationsspezifisches Format entwickeln.
    Ich glaube das wird erstmal zu aufwändig jetzt direkt mit einem eigenen Format anzufangen.

    Gibt es ganz sicher keinen einzigen Weg, das Format der Keyvalue abzufragen?

  • macmoonshine schrieb:

    prettygirl schrieb:

    Gibt es ganz sicher keinen einzigen Weg, das Format der Keyvalue abzufragen?
    Du kannst dir den Wert über objectForKey: holen, und die Klasse prüfen. BOOLs und Zahlen erhältst du dabei aber als NSNumber.
    aber in swift gibt es wohl keine möglichkeit zu erkennen ob in NSNumber ein int oder ein bool gespeichert wurde. In obj-c ist es hingegen möglich.

  • Ich habe das Problem zwischenzeitlich lösen können:
    1. Ich frage mit objectForKey den Wert des Keys ab .
    2. ich sende den wert an eine Funktion.
    3. Die Funktion überprüft, ob der Wert den erwarteten Datentyp hat (mittels String(VarToCheck.dynamicType) == "__NSCFBoolean" ab und gibt einen bool zurück
    4. Ist der zurückgegebene bool false, wird die Datei wiederhergestellt

    Danke an eure Hilfen <X <X <X

  • torquato schrieb:

    In der Swift-'community' besteht der überwiegende Konsens, daß solche sprachlich nicht notwendigen Klammern möglichst nicht gesetzt werden. Sie erhöhen nur das Buchstaben-Grundrauschen im Code, haben aber keine eigene Funktion...
    Gilt das auch für runde Klammern bei Funktionsdeklarationen, -definitionen und -aufrufen?
    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"?

  • torquato schrieb:

    Ja. Absolut richtig. Code-Verständlichkeit und -Lesbarkeit hat absolute Top-1 Priorität.
    Und wieso ersetzt man dann sprechende Schlüsselwörter mit Sonderzeichen?

    torquato schrieb:

    In C werden die Klammern doch überhaupt nur gebraucht, weil vor ca. 30 Jahren man es noch nicht besser konnte.
    Man konnte es sicherlich besser, wollte es aber nicht. Wegen der Lesbarkeit.
    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"?

  • torquato schrieb:

    In C: Nein
    In Swift: Ja

    Swift verlang unbedingt {}. Aus sehr gutem Grund. Damit eben der scope _immer_ klar ist. Aus dem gleichen Grund ist switch in Swift kein fallthrough.
    Das hat damit nichts zu tun. Ein Ausdruck, wie er im if steht, müsste mit einem binären oder ternären Operator fortgeführt werden. Ein neuer Ausdruck im Body würde nicht mit einem solchen Operator beginnen. Das ließe sich also feststellen. (Und selbst wenn man einen missverständlichen Fall konstruieren könnte, wäre das kein Hinderungsgrund, weil man dann immer noch klammern könnte. Das ist ja nichts Ungewöhnliches in jeder Programmiersprache.)
    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"?

  • torquato schrieb:

    gritsch schrieb:

    torquato schrieb:

    Genau. Und auf die Leserlichkeit wollte ich abzielen. Überflüssiger Buchstabensalat hilft da idR nicht.
    dann kommen die anderen programmierer wieder und sagen dass {} für nur einen befehl "überflüssiger buchstabensalat" ist und auch der compiler dies nicht braucht weil er den scope dann kennt...
    Mmmhh... Wird doch schon gemacht. Wer ist das nochmal...? Python oder Ruby. Irgendeiner von den beiden setzt soweit ich weiß auf Tab(?)-Einrückung, statt auf Klammern. Sowas kann man sich dann überflüssigerweise sehr leicht mit seinen Xcode/IDE-Einstellungen zerschießen.
    Ist doch nur eine Sache von Coding-Style. Machen wir nicht zuviel Wirbel drum.^^
    Wieso ist denn () überflüssiger Buchstabensalat und {} kein überflüssiger Buchstabensalat?
    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"?

  • macmoonshine schrieb:

    prettygirl schrieb:

    Gibt es ganz sicher keinen einzigen Weg, das Format der Keyvalue abzufragen?
    Du kannst dir den Wert über objectForKey: holen, und die Klasse prüfen. BOOLs und Zahlen erhältst du dabei aber als NSNumber.
    Das ist jetzt aber wesentlich mehr unswifty als runde Klammern um Kontrollflusskonstrukte.
    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:

    macmoonshine schrieb:

    prettygirl schrieb:

    Gibt es ganz sicher keinen einzigen Weg, das Format der Keyvalue abzufragen?
    Du kannst dir den Wert über objectForKey: holen, und die Klasse prüfen. BOOLs und Zahlen erhältst du dabei aber als NSNumber.
    Das ist jetzt aber wesentlich mehr unswifty als runde Klammern um Kontrollflusskonstrukte.
    Ach, du kannst ja ein paar Ausrufe- und Fragezeichen sowie beliebige Schimpftiraden aus Asterix-Heften einstreuen, damit es swiftiger wird.
    „Meine Komplikation hatte eine Komplikation.“

  • torquato schrieb:

    ...

    prettygirl schrieb:

    Quellcode

    1. if (test >= 0) {


    ...
    In Swift kann, ja sollte man sogar besser auf diese Klammern verzichten.

    In der Swift-'community' besteht der überwiegende Konsens, daß solche sprachlich nicht notwendigen Klammern möglichst nicht gesetzt werden. Sie erhöhen nur das Buchstaben-Grundrauschen im Code, haben aber keine eigene Funktion...

    Echt jetzt?
    Da hat sich der Lattner mit seinen Kumpanen doch wieder unsinnigen Blödsinn einfallen lassen.

    Nehmen wir ein simples Beispiel:

    Quellcode

    1. if (test >1 && test <4) {


    Wenn es nach den Ideen der Swift Community ginge, dann müsste ja auch folgender Murks kompilieren:

    Quellcode

    1. if test >1 and <4 {


    Es ist ja vom Kontext her offensichtlich, dass sich auf test bezogen wird. Wozu also diese sinnlose Verdopplung?

    Noch besser wäre sogar

    Quellcode

    1. if test between 1 and 4 including { ... }
    2. // Beziehungsweise
    3. if test between 0 and 5 excluding { ... }


    Das liest sich dann fast wie Smalltalk.

    Quellcode

    1. if test isBetween:1 and:4 includeGivenNumbers:YES


    Was mitunter zu Problemen führen kann. Gehört das and jetzt zu test (zweiter zu prüfender Teil) oder zu 1 (Addition)?
    Kann man ja zur Übersicht klammern.

    Quellcode

    1. if (test isBetween:1 and:4 includeGivenNumbers:YES)


    Woran erinnert uns das?

    Quellcode

    1. if [test isBetween:1 and:4 includeGivenNumbers:YES]


    Aber uns Chris optimiert vermutlich eher zu

    Quellcode

    1. if test <> (1,4) {


    Total sprechend, wie man es gewohnt ist. ^^
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P