Optionals, Optionals - wieso eigentlich

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

  • Markus Müller schrieb:

    gritsch schrieb:

    Markus Müller schrieb:

    gritsch schrieb:

    Markus Müller schrieb:

    Mit dem optionals-Konstrukt lässt sich ein Konzept explizit ausdrücken. Ein optionaler Wert kann einen Wert enthalten oder eben auch nicht. Wenn man es nicht nur als syntaktischen Zucker für obj-c Zeiger versteht, bietet dieser Sprachmechanismus wesentlich ausdrucksvolleren Code. Es funktioniert ja auch mit integers etc. Und es nicht möglich, wie in objc versehentlich eine nil-Referenz herumzureichen, ohne dass es der Compiler bemerkt.
    ja für normale typen bzw structs sehe ich es ein. bei objekten aber nicht. denn das problem "unbemerktes nil rumreichen" gibt es ja nicht weil man das überall abfragen kann (und das tut auch gar nicht weh).
    Du hast aber nicht über jeden Code Kontrolle. Es kann eben unbemerkt passieren, mit optionals siehst Du es an der Signatur des verwendeten Codes, was Du reingeben darfst und was nicht. (schönes Beispiel ist NSStrings compare: - Du darfst kein nil reinreichen, aber Du kannst es trotzdem machen. In swift kompiliert solcher Code nicht).
    doch, ich habe kontrolle über den code. wenn ich irgendwas irgendwoher bekomme, kann ich es überprüfen, und wenn ich irgendwas an irgendwen sende, kann ich auch kontrollieren ob es nil ist oder nicht (und meistens darf es auch nil sein weil es eben der empfänger korrekt handelt).in welchen situationen wird denn compare: verwendet ohne dass sichergestellt ist dass der parameter nicht nil ist?
    normal verwendet man es doch nur zum sortieren. und dort gibt es ja zwei objekte sonst müsste man nicht sortieren!
    Du musst im Grunde JEDE Objektreferenz auf nil testen, wenn nil nicht erlaubt ist. Das Problem ist, dass der Code kompiliert, wenn Du es trotzdem machst und Du es erst zur Laufzeit bemerkst. Aber das hatte ich auch schon weiter oben geschrieben...
    ja aber jede methode prüft einfach seine parameter und fertig.

    viel schlimmer sind solche ketten in swift: irgendwas!.nochwas!.irgendwasanderes
    der compiler sagt da auch nix dazu und dann zur laufzeit knallt es.

  • macmoonshine schrieb:

    Markus Müller schrieb:

    Du darfst kein nil reinreichen, aber Du kannst es trotzdem machen. In swift kompiliert solcher Code nicht).
    Das nil kommt ja nicht einfach so in die compare:-Methode. Der Fehler liegt dann wahrscheinlich schon vorher. Und dann bricht der Swift-Code da, und das wahrscheinlich eben auch zur Lauf- und nicht zur Übersetzungszeit.
    Na zumindest nativer swift-code würde das dann nicht zulassen beim kompilieren. Die jetzige Übergangszeit mit den obj-c Cocoa-API's bereitet diesbzgl. die einen oder anderen Schmerzen, richtig...

  • gritsch schrieb:

    Markus Müller schrieb:

    gritsch schrieb:

    Markus Müller schrieb:

    gritsch schrieb:

    Markus Müller schrieb:

    Mit dem optionals-Konstrukt lässt sich ein Konzept explizit ausdrücken. Ein optionaler Wert kann einen Wert enthalten oder eben auch nicht. Wenn man es nicht nur als syntaktischen Zucker für obj-c Zeiger versteht, bietet dieser Sprachmechanismus wesentlich ausdrucksvolleren Code. Es funktioniert ja auch mit integers etc. Und es nicht möglich, wie in objc versehentlich eine nil-Referenz herumzureichen, ohne dass es der Compiler bemerkt.
    ja für normale typen bzw structs sehe ich es ein. bei objekten aber nicht. denn das problem "unbemerktes nil rumreichen" gibt es ja nicht weil man das überall abfragen kann (und das tut auch gar nicht weh).
    Du hast aber nicht über jeden Code Kontrolle. Es kann eben unbemerkt passieren, mit optionals siehst Du es an der Signatur des verwendeten Codes, was Du reingeben darfst und was nicht. (schönes Beispiel ist NSStrings compare: - Du darfst kein nil reinreichen, aber Du kannst es trotzdem machen. In swift kompiliert solcher Code nicht).
    doch, ich habe kontrolle über den code. wenn ich irgendwas irgendwoher bekomme, kann ich es überprüfen, und wenn ich irgendwas an irgendwen sende, kann ich auch kontrollieren ob es nil ist oder nicht (und meistens darf es auch nil sein weil es eben der empfänger korrekt handelt).in welchen situationen wird denn compare: verwendet ohne dass sichergestellt ist dass der parameter nicht nil ist?normal verwendet man es doch nur zum sortieren. und dort gibt es ja zwei objekte sonst müsste man nicht sortieren!
    Du musst im Grunde JEDE Objektreferenz auf nil testen, wenn nil nicht erlaubt ist. Das Problem ist, dass der Code kompiliert, wenn Du es trotzdem machst und Du es erst zur Laufzeit bemerkst. Aber das hatte ich auch schon weiter oben geschrieben...
    ja aber jede methode prüft einfach seine parameter und fertig.
    viel schlimmer sind solche ketten in swift: irgendwas!.nochwas!.irgendwasanderes
    der compiler sagt da auch nix dazu und dann zur laufzeit knallt es.
    Das stimmt, diese !Ketten sind schlimm. Deshalb macht man das auch so nicht...

  • tsunamix schrieb:

    Das verstehe ich nicht. Was meinst Du damit?
    Du hast beispielsweise eine Klasse, die Datenbankzeilen darstellt. Die hat eine Property für den Primärschlüssel. Jetzt willst du eine neue Zeile anlegen. Dann musst du zuerst ein Objekt anlegen, das noch keinen Primärschlüsselwert hat. Andererseits sind Primärschlüssel das Paradebeispiel für Werte, die nicht nil sein dürfen.
    „Meine Komplikation hatte eine Komplikation.“

  • Markus Müller schrieb:

    gritsch schrieb:

    Markus Müller schrieb:

    gritsch schrieb:

    Markus Müller schrieb:

    gritsch schrieb:

    Markus Müller schrieb:

    Mit dem optionals-Konstrukt lässt sich ein Konzept explizit ausdrücken. Ein optionaler Wert kann einen Wert enthalten oder eben auch nicht. Wenn man es nicht nur als syntaktischen Zucker für obj-c Zeiger versteht, bietet dieser Sprachmechanismus wesentlich ausdrucksvolleren Code. Es funktioniert ja auch mit integers etc. Und es nicht möglich, wie in objc versehentlich eine nil-Referenz herumzureichen, ohne dass es der Compiler bemerkt.
    ja für normale typen bzw structs sehe ich es ein. bei objekten aber nicht. denn das problem "unbemerktes nil rumreichen" gibt es ja nicht weil man das überall abfragen kann (und das tut auch gar nicht weh).
    Du hast aber nicht über jeden Code Kontrolle. Es kann eben unbemerkt passieren, mit optionals siehst Du es an der Signatur des verwendeten Codes, was Du reingeben darfst und was nicht. (schönes Beispiel ist NSStrings compare: - Du darfst kein nil reinreichen, aber Du kannst es trotzdem machen. In swift kompiliert solcher Code nicht).
    doch, ich habe kontrolle über den code. wenn ich irgendwas irgendwoher bekomme, kann ich es überprüfen, und wenn ich irgendwas an irgendwen sende, kann ich auch kontrollieren ob es nil ist oder nicht (und meistens darf es auch nil sein weil es eben der empfänger korrekt handelt).in welchen situationen wird denn compare: verwendet ohne dass sichergestellt ist dass der parameter nicht nil ist?normal verwendet man es doch nur zum sortieren. und dort gibt es ja zwei objekte sonst müsste man nicht sortieren!
    Du musst im Grunde JEDE Objektreferenz auf nil testen, wenn nil nicht erlaubt ist. Das Problem ist, dass der Code kompiliert, wenn Du es trotzdem machst und Du es erst zur Laufzeit bemerkst. Aber das hatte ich auch schon weiter oben geschrieben...
    ja aber jede methode prüft einfach seine parameter und fertig.viel schlimmer sind solche ketten in swift: irgendwas!.nochwas!.irgendwasanderes
    der compiler sagt da auch nix dazu und dann zur laufzeit knallt es.
    Das stimmt, diese !Ketten sind schlimm. Deshalb macht man das auch so nicht...
    aha, warum macht man das dann nicht so, in obj-c darf man aber nicht auf nil prüfen!? man muss eben doch manchmal was tun und kann nicht nur definieren "das programm soll schuhe katalogisieren und mich benachrichtigen wenn neue modelle von kunden gut angenommen werden". programmiersprache mach jetzt mal alles automatisch!

  • Michael schrieb:

    macmoonshine schrieb:

    Das kommt mir alles so bekannt vor. Ja, va s war das nur für eine Programmiersprache, die auch keine Pointer hatte.
    Letztendlich arbeiten doch alle Programmiersprachen mit Pointern. Es wird halt nur vorm Programmierer „versteckt“.
    Genau, ich habe auch nichts gegen Pointer. Mich nervt nur, dass man immer wieder erzählt bekommt, es ginge auch ohne.
    „Meine Komplikation hatte eine Komplikation.“

  • gritsch schrieb:

    viel schlimmer sind solche ketten in swift: irgendwas!.nochwas!.irgendwasanderes
    der compiler sagt da auch nix dazu und dann zur laufzeit knallt es.

    Wenn man explizit dem Compiler sagt, "Ich weiß es besser als Du. Mach trotzdem!" – genau dazu ist das ! da – dann sollte man sich nicht beschweren. In C/Objetive-C kann man auch explizit casten und dann auf die Schnauze fallen....

  • tsunamix schrieb:

    macmoonshine schrieb:

    Markus Müller schrieb:

    Und es nicht möglich, wie in objc versehentlich eine nil-Referenz herumzureichen, ohne dass es der Compiler bemerkt.
    Das ist genau das, was ich mit Illusion meine, weil du nämlich häufig Optionals anstatt Non-Optionals verwenden musst. Gerade Properties müssen beispielsweise häufig Null-Werte zulassen, obwohl ein Null-Wert einen Fehler darstellt.
    Das verstehe ich nicht. Was meinst Du damit?
    Einfachstes Beispiel wären Outlets. Wie oft hast du schon Outlets deklariert, die nicht initialisiert werden müssen und ein Programm trotzdem voll funktionsfähig ist? Ein nicht initialisiertes Outlet ist in 99% der Fälle ein Fehler.

  • tsunamix schrieb:

    gritsch schrieb:

    viel schlimmer sind solche ketten in swift: irgendwas!.nochwas!.irgendwasanderes
    der compiler sagt da auch nix dazu und dann zur laufzeit knallt es.
    Wenn man explizit dem Compiler sagt, "Ich weiß es besser als Du. Mach trotzdem!" – genau dazu ist das ! da – dann sollte man sich nicht beschweren. In C/Objetive-C kann man auch explizit casten und dann auf die Schnauze fallen....
    wo willst du jetzt irgendwas casten? wir sind bei optionals.
    ihr wollt uns in obj-c verbieten auf nil zu prüfen, in swift gehts dann aber doch auch nicht ohne prüfen. also was soll das ganze.

    meiner meinung nach braucht man in obj-c keine optionals da wir eh bereits optionals haben.
    optionals wären manchmal praktisch für einfache typen und structs, aber das liegt ja nicht an obj-c sondern kommt von C.

  • Markus Müller schrieb:

    Na zumindest nativer swift-code würde das dann nicht zulassen beim kompilieren. Die jetzige Übergangszeit mit den obj-c Cocoa-API's bereitet diesbzgl. die einen oder anderen Schmerzen, richtig...
    Das hat doch nichts mit nativem oder nicht-nativem Swift-Code zu tun. Das Problem liegt darin, dass man an manchen Stelle n Nil-Pointer zulassen muss und an anderen nicht. Und es gibt immer Übergangsstellen, wo dir auch kein Compiler weiterhelfen kann.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    tsunamix schrieb:

    Das verstehe ich nicht. Was meinst Du damit?
    Du hast beispielsweise eine Klasse, die Datenbankzeilen darstellt. Die hat eine Property für den Primärschlüssel. Jetzt willst du eine neue Zeile anlegen. Dann musst du zuerst ein Objekt anlegen, das noch keinen Primärschlüsselwert hat. Andererseits sind Primärschlüssel das Paradebeispiel für Werte, die nicht nil sein dürfen.
    Programmlogik überdenken (wo wird der Schlüssel vergeben?), bzw. möglicherweise einer der seltenen Fälle für eine Typdeklaration mit einem explicitly unwrapped Optional, e.g. var key: Int!.

  • tsunamix schrieb:

    macmoonshine schrieb:

    tsunamix schrieb:

    Das verstehe ich nicht. Was meinst Du damit?
    Du hast beispielsweise eine Klasse, die Datenbankzeilen darstellt. Die hat eine Property für den Primärschlüssel. Jetzt willst du eine neue Zeile anlegen. Dann musst du zuerst ein Objekt anlegen, das noch keinen Primärschlüsselwert hat. Andererseits sind Primärschlüssel das Paradebeispiel für Werte, die nicht nil sein dürfen.
    Programmlogik überdenken (wo wird der Schlüssel vergeben?), bzw. möglicherweise einer der seltenen Fälle für eine Typdeklaration mit einem explicitly unwrapped Optional, e.g. var key: Int!.
    Ich habe extra ein relativ häufiges Pattern als Beispiel gewählt. Es geht auch nicht darum, das Problem schöner zu vertuschen. Es geht vielmehr um eine angebliche Lösung, die keine ist. Swift-Optionals geben dir nur das gute Gefühl, keine Null-Pointer-Fehler machen zu können.
    „Meine Komplikation hatte eine Komplikation.“

  • gritsch schrieb:

    tsunamix schrieb:

    gritsch schrieb:

    viel schlimmer sind solche ketten in swift: irgendwas!.nochwas!.irgendwasanderes
    der compiler sagt da auch nix dazu und dann zur laufzeit knallt es.
    Wenn man explizit dem Compiler sagt, "Ich weiß es besser als Du. Mach trotzdem!" – genau dazu ist das ! da – dann sollte man sich nicht beschweren. In C/Objetive-C kann man auch explizit casten und dann auf die Schnauze fallen....
    wo willst du jetzt irgendwas casten? wir sind bei optionals.ihr wollt uns in obj-c verbieten auf nil zu prüfen, in swift gehts dann aber doch auch nicht ohne prüfen. also was soll das ganze.

    meiner meinung nach braucht man in obj-c keine optionals da wir eh bereits optionals haben.
    optionals wären manchmal praktisch für einfache typen und structs, aber das liegt ja nicht an obj-c sondern kommt von C.
    Das mit dem cast war ein Vergleich. Wenn Du in C einen void-Pointer nach Deinem Gusto castest, macht man eine genauso unsichere Behauptung, wie wenn man in Swift ein Optional explizit unwrapped. Ergo: Man sollte diese Ausrufezeichen in Swift tunlichst vermeiden.

    Hier will Dir niemand etwas verbieten. Solche Prüfungen sind nötig, sie funktionieren in Obj-C und Swift nur oft anders.

    Obj-C hat keine Optionals, und das Konzept hat da auch nichts verloren.

  • macmoonshine schrieb:

    Markus Müller schrieb:

    Na zumindest nativer swift-code würde das dann nicht zulassen beim kompilieren. Die jetzige Übergangszeit mit den obj-c Cocoa-API's bereitet diesbzgl. die einen oder anderen Schmerzen, richtig...
    Das hat doch nichts mit nativem oder nicht-nativem Swift-Code zu tun. Das Problem liegt darin, dass man an manchen Stelle n Nil-Pointer zulassen muss und an anderen nicht. Und es gibt immer Übergangsstellen, wo dir auch kein Compiler weiterhelfen kann.
    doch, denn Du kannst in swift angeben, ob Du optionale Werte verarbeitest oder eben nicht. Wenn Du optionals erwartest, musst Du den nil-Fall prüfen, genau das drückt der Code ja aus. Das meinte ich mit ausdrucksvollerem Code weiter oben. In obj hast Du immer nur Typ*

  • tsunamix schrieb:

    gritsch schrieb:

    tsunamix schrieb:

    gritsch schrieb:

    viel schlimmer sind solche ketten in swift: irgendwas!.nochwas!.irgendwasanderes
    der compiler sagt da auch nix dazu und dann zur laufzeit knallt es.
    Wenn man explizit dem Compiler sagt, "Ich weiß es besser als Du. Mach trotzdem!" – genau dazu ist das ! da – dann sollte man sich nicht beschweren. In C/Objetive-C kann man auch explizit casten und dann auf die Schnauze fallen....
    wo willst du jetzt irgendwas casten? wir sind bei optionals.ihr wollt uns in obj-c verbieten auf nil zu prüfen, in swift gehts dann aber doch auch nicht ohne prüfen. also was soll das ganze.
    meiner meinung nach braucht man in obj-c keine optionals da wir eh bereits optionals haben.
    optionals wären manchmal praktisch für einfache typen und structs, aber das liegt ja nicht an obj-c sondern kommt von C.
    Das mit dem cast war ein Vergleich. Wenn Du in C einen void-Pointer nach Deinem Gusto castest, macht man eine genauso unsichere Behauptung, wie wenn man in Swift ein Optional explizit unwrapped. Ergo: Man sollte diese Ausrufezeichen in Swift tunlichst vermeiden.
    Hier will Dir niemand etwas verbieten. Solche Prüfungen sind nötig, sie funktionieren in Obj-C und Swift nur oft anders.

    Obj-C hat keine Optionals, und das Konzept hat da auch nichts verloren.
    doch, obj-c hat optionals bei objektpointern denn du kannst ihnen nil zuweisen (das ist bei obj-c im prinzip der "kein wert" indikator der optionals bei swift).
    nur in C gibts keine optionals.

    und warum soll man die rufezeichen in swift vermeiden, in obj-c aber keine if-abfragen machen?
    du musst eben in beiden sprachen bestimmte sachen machen oder eben nicht machen dass es funktioniert.
    ob man dann lieber ein fragezeichen und sonstige konstrukte verwendet oder eine gebräuchliches für jeden lesbares if-statement ist doch komplett egal!

  • gritsch schrieb:

    tsunamix schrieb:

    gritsch schrieb:

    tsunamix schrieb:

    gritsch schrieb:

    viel schlimmer sind solche ketten in swift: irgendwas!.nochwas!.irgendwasanderes
    der compiler sagt da auch nix dazu und dann zur laufzeit knallt es.
    Wenn man explizit dem Compiler sagt, "Ich weiß es besser als Du. Mach trotzdem!" – genau dazu ist das ! da – dann sollte man sich nicht beschweren. In C/Objetive-C kann man auch explizit casten und dann auf die Schnauze fallen....
    wo willst du jetzt irgendwas casten? wir sind bei optionals.ihr wollt uns in obj-c verbieten auf nil zu prüfen, in swift gehts dann aber doch auch nicht ohne prüfen. also was soll das ganze.meiner meinung nach braucht man in obj-c keine optionals da wir eh bereits optionals haben.
    optionals wären manchmal praktisch für einfache typen und structs, aber das liegt ja nicht an obj-c sondern kommt von C.
    Das mit dem cast war ein Vergleich. Wenn Du in C einen void-Pointer nach Deinem Gusto castest, macht man eine genauso unsichere Behauptung, wie wenn man in Swift ein Optional explizit unwrapped. Ergo: Man sollte diese Ausrufezeichen in Swift tunlichst vermeiden.Hier will Dir niemand etwas verbieten. Solche Prüfungen sind nötig, sie funktionieren in Obj-C und Swift nur oft anders.

    Obj-C hat keine Optionals, und das Konzept hat da auch nichts verloren.
    doch, obj-c hat optionals bei objektpointern denn du kannst ihnen nil zuweisen (das ist bei obj-c im prinzip der "kein wert" indikator der optionals bei swift).nur in C gibts keine optionals.

    und warum soll man die rufezeichen in swift vermeiden, in obj-c aber keine if-abfragen machen?
    du musst eben in beiden sprachen bestimmte sachen machen oder eben nicht machen dass es funktioniert.
    ob man dann lieber ein fragezeichen und sonstige konstrukte verwendet oder eine gebräuchliches für jeden lesbares if-statement ist doch komplett egal!
    ich habe nirgends geschrieben, dass Du in obj-c keine nil tests machen darfst. In Swift kannst Du aber explizit sagen, dass eine Wert niemals nil sein kann. Dann brauchst Du Dich auch niemals drum kümmern, keine !-Ketten und hast Hilfe vom Compiler das durchzusetzen. Wenn werte optional sein können, siehst Du es sofort und musst den Fall auch behandeln. Was daran so schwer zu verstehen ist, verstehe ich nicht...

  • Markus Müller schrieb:

    gritsch schrieb:

    tsunamix schrieb:

    gritsch schrieb:

    tsunamix schrieb:

    gritsch schrieb:

    viel schlimmer sind solche ketten in swift: irgendwas!.nochwas!.irgendwasanderes
    der compiler sagt da auch nix dazu und dann zur laufzeit knallt es.
    Wenn man explizit dem Compiler sagt, "Ich weiß es besser als Du. Mach trotzdem!" – genau dazu ist das ! da – dann sollte man sich nicht beschweren. In C/Objetive-C kann man auch explizit casten und dann auf die Schnauze fallen....
    wo willst du jetzt irgendwas casten? wir sind bei optionals.ihr wollt uns in obj-c verbieten auf nil zu prüfen, in swift gehts dann aber doch auch nicht ohne prüfen. also was soll das ganze.meiner meinung nach braucht man in obj-c keine optionals da wir eh bereits optionals haben.optionals wären manchmal praktisch für einfache typen und structs, aber das liegt ja nicht an obj-c sondern kommt von C.
    Das mit dem cast war ein Vergleich. Wenn Du in C einen void-Pointer nach Deinem Gusto castest, macht man eine genauso unsichere Behauptung, wie wenn man in Swift ein Optional explizit unwrapped. Ergo: Man sollte diese Ausrufezeichen in Swift tunlichst vermeiden.Hier will Dir niemand etwas verbieten. Solche Prüfungen sind nötig, sie funktionieren in Obj-C und Swift nur oft anders.
    Obj-C hat keine Optionals, und das Konzept hat da auch nichts verloren.
    doch, obj-c hat optionals bei objektpointern denn du kannst ihnen nil zuweisen (das ist bei obj-c im prinzip der "kein wert" indikator der optionals bei swift).nur in C gibts keine optionals.
    und warum soll man die rufezeichen in swift vermeiden, in obj-c aber keine if-abfragen machen?
    du musst eben in beiden sprachen bestimmte sachen machen oder eben nicht machen dass es funktioniert.
    ob man dann lieber ein fragezeichen und sonstige konstrukte verwendet oder eine gebräuchliches für jeden lesbares if-statement ist doch komplett egal!
    ich habe nirgends geschrieben, dass Du in obj-c keine nil tests machen darfst. In Swift kannst Du aber explizit sagen, dass eine Wert niemals nil sein kann. Dann brauchst Du Dich auch niemals drum kümmern, keine !-Ketten und hast Hilfe vom Compiler das durchzusetzen. Wenn werte optional sein können, siehst Du es sofort und musst den Fall auch behandeln. Was daran so schwer zu verstehen ist, verstehe ich nicht...
    ja aber in den meisten fällen ist es mir doch egal ob da nil kommt oder nicht. ich kann daran nachrichten senden und ich kann es zuweisen.
    es gibt halt einige ausnahmen in denen man keine nil-pointer übergeben darf aber die kennt man ja bzw sind logisch und es steht in der doku und außerdem noch durch nonnull oder nullable gekennzeichnet.

  • Markus Müller schrieb:

    doch, denn Du kannst in swift angeben, ob Du optionale Werte verarbeitest oder eben nicht. Wenn Du optionals erwartest, musst Du den nil-Fall prüfen, genau das drückt der Code ja aus. Das meinte ich mit ausdrucksvollerem Code weiter oben. In obj hast Du immer nur Typ*
    Du meinst, dass Code ausdrucksvoller ist, wenn er voll von Frage- und Ausrufezeichen ist? Gerade die Optional-Syntax ist doch genau das Gegenteil von ausdrucksvoll. Und ein if let finde ich auch nicht ausdrucksstärker als einen expliziten Vergleich auf nil.
    „Meine Komplikation hatte eine Komplikation.“