Optionals, Optionals - wieso eigentlich

  • gritsch schrieb:

    ebenso das hat nichts mit optionals zu tun!
    Doch natürlich, womit denn sonst?

    Markus Müller schrieb:

    um zwei komplett unterschiedliche Typen handelt. Man kann also nicht versehentlich beide Konzepte vermischen. In obj-c ist das möglich und dann knallt es u.U. erst zur Laufzeit, in Swift findet es der Compiler.
    Das halte ich für eine Illusion. Variablen, die niemals nil sein dürfen, sind meistens Konstanten, und der Compiler kann dabei nur so gut sein, wie der Programmierer sein Konzept durchdacht hat. Dafür handelt man sich einen riesigen Haufen syntaktischen Overhead ein.
    „Meine Komplikation hatte eine Komplikation.“

  • 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.

  • tsunamix schrieb:

    Optionals sollen sicherstellen, daß ein Variable IMMER einen Wert hat.
    Das kann ja gar nicht sein, denn sonst könnte man einem Optional ja eben nicht „nix“ zuweisen. Anders herum wird da ein Schuh draus. „Normale“ Variablen dürfen in Swift nicht uninitialisiert sein. Optionals dürfen hingegen auch „keinen Wert“ enthalten. Man darf ihnen sogar „keinen Wert“ zuweisen. Mit nil hat Objective-C etwas ähnliches, aber das zieht nur bei Objekten. Optionals sind auf alle Typen anwendbar. So Dinger wie NSNotFound braucht man bei Optionals nicht.

  • macmoonshine schrieb:

    gritsch schrieb:

    Man kann es jedoch nicht mit obj-c vergleichen weil es das konstrukt dort nicht gibt.
    Man könnte auch sagen: In Objective-C ist jede Objektreferenz ein Optional. ;) +hink+ +hink+
    Eher ein 'Tri-Optional'.

    1.) Referenz initialisiert
    2.) Referenz ist nil
    3.) Referenz ist nicht initialisiert und verweist ins Nirvana

    Um Variante 3.) auszuschließen, genau dafür gibt es Optionals in Swift. Und um dem Programmierer transparent mitzuteilen, daß in diesem Fall neben Variante 1.) auch 2.) möglich ist.

  • 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).

  • tsunamix schrieb:

    macmoonshine schrieb:

    gritsch schrieb:

    Man kann es jedoch nicht mit obj-c vergleichen weil es das konstrukt dort nicht gibt.
    Man könnte auch sagen: In Objective-C ist jede Objektreferenz ein Optional. ;) +hink+ +hink+
    Eher ein 'Tri-Optional'.
    1.) Referenz initialisiert
    2.) Referenz ist nil
    3.) Referenz ist nicht initialisiert und verweist ins Nirvana

    Um Variante 3.) auszuschließen, genau dafür gibt es Optionals in Swift. Und um dem Programmierer transparent mitzuteilen, daß in diesem Fall neben Variante 1.) auch 2.) möglich ist.
    punkt 3 gibts ja nicht mehr seit ARC. Und bei MRC wanrt einem der analyzer davor.

  • 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).

  • Michael schrieb:

    tsunamix schrieb:

    Optionals sollen sicherstellen, daß ein Variable IMMER einen Wert hat.
    Das kann ja gar nicht sein, denn sonst könnte man einem Optional ja eben nicht „nix“ zuweisen. Anders herum wird da ein Schuh draus. „Normale“ Variablen dürfen in Swift nicht uninitialisiert sein. Optionals dürfen hingegen auch „keinen Wert“ enthalten. Man darf ihnen sogar „keinen Wert“ zuweisen. Mit nil hat Objective-C etwas ähnliches, aber das zieht nur bei Objekten. Optionals sind auf alle Typen anwendbar. So Dinger wie NSNotFound braucht man bei Optionals nicht.
    Vielleicht etwas unsauber formuliert. Ich meinte immer initialisiert. In Swift ist es nicht möglich mit uninitilisiertem Speicher rumzufuhrwerken. (Es sei denn man arbeitet mit Unsafe[Mutable]Pointer-Typen natürlich.)

    Guter Hinweis, daß Optionals in Swift alle Typen betreffen.

  • 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.

    Michael schrieb:

    So Dinger wie NSNotFound braucht man bei Optionals nicht.
    Deswegen sind Optionals letztendlich auch nichts anderes als Pointer.

    Das kommt mir alles so bekannt vor. Ja, va s war das nur für eine Programmiersprache, die auch keine Pointer hatte. ;)
    „Meine Komplikation hatte eine Komplikation.“

  • 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!

  • macmoonshine schrieb:

    gritsch schrieb:

    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).
    Es gibt ja neuerdings auch diese tollen Annotationen in Objective-C dafür. ;)
    ja aber dort kann der compiler das nur extrem eingeschränkt erkennen (siehe anderen thread).

  • 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).
    Dafür gibt es doch jetzt diese vieeeel eleganteren Konstrukte wie _Nullable und _Nonnull. :D

  • 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...

  • 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.
    „Meine Komplikation hatte eine Komplikation.“

  • 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?