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

  • Okay, super, danke, dass hat funktioniert, ich werde mich dazu wohl noch etwas informieren müssen
    :/

    ich habe inzwischen eine Lösung für das Problem gefunden, aber egal ob ich beim Auslesen des Keys (testdic.["testkey"]) as! String (ist hier das ! angebracht?) oder String(testdic.["testkey"]) schreibe, ich bekomme immer sowas wie Optional(7), wie kann ich das ändern, dass es wirklich als String ausgelesen wird ?

  • prettygirl schrieb:

    Okay, super, danke, dass hat funktioniert, ich werde mich dazu wohl noch etwas informieren müssen
    :/

    ich habe inzwischen eine Lösung für das Problem gefunden, aber egal ob ich beim Auslesen des Keys (testdic.["testkey"]) as! String (ist hier das ! angebracht?) oder String(testdic.["testkey"]) schreibe, ich bekomme immer sowas wie Optional(7), wie kann ich das ändern, dass es wirklich als String ausgelesen wird ?
    nein das ! ist auch hier nicht korrekt!

    das kommt doch darauf an was da ausgelesen wird. also wie es gespeichert ist. wenn das als nummer gespeichert wird bekommst du eine nummer. du kannst es ja konvertieren wenn du willst.

  • gritsch schrieb:

    Auch wenn es nicht nötig ist, hilft es doch ungemein den code verständlicher zu machen und das ist das ALLERWICHTIGSTE!

    Ja. Absolut richtig. Code-Verständlichkeit und -Lesbarkeit hat absolute Top-1 Priorität. Deswegen spreche ich das ja auch an.
    Wieso sollen da die Klammern helfen, die Boolean-Expression zu verstehen?

    ]if (test >= 0) {

    Ist nicht klarer als

    ]if test >= 0 {

    In C werden die Klammern doch überhaupt nur gebraucht, weil vor ca. 30 Jahren man es noch nicht besser konnte.

    Ich bin absolut der Überzeugung, daß überflüssiger Buchstabensalat normalerweise vermieden werden sollte.
    Natürlich gibt es aber auch Fälle, in denen man Klammern setzen muß.Z.B. um (a * b) + c von a * ( b + c) abzugrenzen.
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • es ist lesbarer und fertig.

    auf if muss ja auch nicht unbedingt {} folgen aber man macht es eben weil es übersichtlicher ist.

    man braucht auch keine newlines und vielerorts keine leerzeichen, man macht es aber trotzdem weil es leserlicher ist.

    also warum jetzt irgendwas wegstreichen was dem benutzer hilft?

    dem compiler ist es ja eh egal und manchmal braucht er sie ja eben auch weil er sonst nicht weiß was zusammengehört.

  • Zu den Klammern: die benutze ich, damit das für mich übersichtlicher bleibt, ob das für dich jetzt überflüssig ist oder nicht, mir hilft und sieht so, meiner Meinung nach, besser aus :)

    gritsch schrieb:

    [...]

    nein das ! ist auch hier nicht korrekt!
    das kommt doch darauf an was da ausgelesen wird. also wie es gespeichert ist. wenn das als nummer gespeichert wird bekommst du eine nummer. du kannst es ja konvertieren wenn du willst.
    Es wird ja wie gesagt aus einer plist ausgelesen und in einem nsdic gespeichert . booleans werden dann auch mit 0 und 1 ausgegeben, um das ganze wirklich besser vergleichen zu können, würde ich gerne jeden key als string ausgegeben und dann einzeln überprüfen, was sie sind, also bei booleans halt gucken, ob ((x == "false") || (x == "true")), bei zahlen ob Int(x) != nil, genauso wie bei strings. nur leider stört das Optional und halt, dass ich nicht den string bekomme .
    :/

  • prettygirl schrieb:

    Zu den Klammern: die benutze ich, damit das für mich übersichtlicher bleibt, ob das für dich jetzt überflüssig ist oder nicht, mir hilft und sieht so, meiner Meinung nach, besser aus :)

    gritsch schrieb:

    [...]

    nein das ! ist auch hier nicht korrekt!
    das kommt doch darauf an was da ausgelesen wird. also wie es gespeichert ist. wenn das als nummer gespeichert wird bekommst du eine nummer. du kannst es ja konvertieren wenn du willst.
    Es wird ja wie gesagt aus einer plist ausgelesen und in einem nsdic gespeichert . booleans werden dann auch mit 0 und 1 ausgegeben, um das ganze wirklich besser vergleichen zu können, würde ich gerne jeden key als string ausgegeben und dann einzeln überprüfen, was sie sind, also bei booleans halt gucken, ob ((x == "false") || (x == "true")), bei zahlen ob Int(x) != nil, genauso wie bei strings. nur leider stört das Optional und halt, dass ich nicht den string bekomme . :/
    zeig mal eine solche beispieldatei (lad sie hier hoch).

    warum musst du wissen ob es ein bool ist oder eine number? kann dir ja egal sein oder?
    jetzt alle werte als strings zu speichern kann nur in die hose gehen (spätestens bei floats, datum oder binärdaten).

  • gritsch schrieb:


    auf if muss ja auch nicht unbedingt {} folgen aber man macht es eben weil es übersichtlicher ist

    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.

    gritsch schrieb:

    man macht es aber trotzdem weil es leserlicher ist.

    Genau. Und auf die Leserlichkeit wollte ich abzielen. Überflüssiger Buchstabensalat hilft da idR nicht.
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • 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.^^
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • 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.^^
    dort geht es um tabs, bei C ist aber egal wie eignerückt das ist. kommt kein eigener scope so wird nur der nächste command ausgeführt. Ich bin kein fan davon und mach immer einen eigenen scope auf der übersichtlichkeit halber. genauso klammere ich auch bei if-statements - egal ob der compiler das braucht oder nicht...

  • torquato schrieb:

    Python oder Ruby. Irgendeiner von den beiden setzt soweit ich weiß auf Tab(?)-Einrückung, statt auf Klammern.
    Das ist Python. Du kannst aber auch Spaces zum Einrücken nehmen. Wichtig ist nur, dass jeweils die Einrückung innerhalb eines Blocks einheitlich ist.

    torquato schrieb:

    Sowas kann man sich dann überflüssigerweise sehr leicht mit seinen Xcode/IDE-Einstellungen zerschießen.
    Es soll ja Editoren geben, die Spaces in Tabs und umgekehrt umwandeln können, und wer seinen Code nicht sauber einrückt, soll lieber Staubsauger verkaufen. ;)
    „Meine Komplikation hatte eine Komplikation.“

  • Okay, habe jetzt noch schnell ein Projekt erstellt, was das ganze verdeutlichen sollte.
    Wenn ihr die App startet, steht in der Konsole folgendes:
    Optional(1) as Bool. Ich hätte es gerne, dass das ganze aber String da steht, damit das besser verglichen werden kann. Zwar funktioniert mein eigentliches Programm, wenn da Zahlen in der plist stehen, aber ich hätte es gerne sauber programmiert, sodass jede Modifikation vom user an der Datei selbst erkannt und verbessert wird.
    Dateien

  • prettygirl schrieb:

    Ich möchte eigentlich den Datentyp überprüfen (siehe Bild), weil es sein kann dass der user die Datei bearbeitet und ich einen Programmfehler vermeiden möchte
    dann vergiss das mit den strings mal ganz schnell wieder.

    und warum muss das programm wissen ob es ein bool ist oder ein int?
    ein int enthällt ja den wertebereicch von bool.

    in obj-c könnte man das lösen: developer.apple.com/library/ma…cc/instm/NSValue/objCType

  • 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
    wenn der buntzer das ändern kann, dann musst du alles mögliche abfragen. also ob er zahlen in den gewünschten ranges eingibt oder doch einen string oder sosntige daten.

    also warum konkret kannst du ein bool nicht als int behandeln?