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

  • Optionals, Optionals - wieso eigentlich

    Optionals?
    Nein, ich will nicht provozieren. Ich will mich auch nicht lustig machen über Swift (dazu würde mir schon die nötige Kompetenz fehlen).
    Ich will es einfach mal verstehen. Und je öfter ich es in Büchern und Dokumenten lese und es in eigenem Source-Code dann sehe, desto weniger verstehe ich, was der effektive Nutzen und Sinn für den Programmierer nun sein soll.

    In Objective-C konnte jedes Objekt auf einen echten Wert oder eben auf nil zeigen. In Swift geht das mit den "normalen" Typen jetzt nicht mehr, nil ist nicht mehr "erlaubt". Dafür wurden Optionals eingeführt, um wieder das zu ermöglichen, was in Objective-C per se schon ging.
    Dass es ein Problem beim Programmablauf geben kann, wenn ein Wert "nil" ist klar, darum musste man eben im Bedarfsfall abfragen, ob da ein Wert oder nil hinterlegt ist.
    Habe ich ein Optional mache ich aber mit all den "if let" Konstrukten auch nix anderes als eben diese Abfrage. Zusätzlich "verschandle" ich die Lesbarkeit im Code mit zig Fragezeichen und Ausrufezeichen, um Optionals anzulegen bzw. auszuwrappen.


    developer.apple.com schrieb:

    Not only are optionals safer and more expressive than nil pointers in Objective-C, they are at the heart of many of Swift’s most powerful features.

    Wo ist dieses Plus an Sicherheit? Übersehe ich da was elementares? Vielleicht sind meine Projekte auch programmiertechnisch zu einfach. Aber die Jungs von Apple müssen sich doch was dabei gedacht haben, als sie Optionals eingeführt haben?

    Vielleicht kann mir das jemand in aller Einfachheit erklären. Oder eben nicht.
  • ich habe mich mit optionals nicht befasst, finde in obj-c das verhalten dass man messages an nil senden kann aber sehr praktisch.
    Ich finde jedoch dass apple da selbst einiges verbockt hat. Warum zb darf der parameter von isEqualToString nicht nil sein?
    in der implementation tut das doch gar nicht weh:

    Quellcode

    1. if (!aString)
    2. {
    3. return NO;
    4. }
  • Der Grund liegt darin, dass Swift und Objective-C sich in der Typisierung komplett unterscheiden.
    Swift->statisch
    Objective-C->dynamisch

    Der Paradigmenwechsel bringt gewisse Vor- aber auch Nachteile mit sich. Bei statischer Typisierung kannst du nicht eine Nachricht an ein Objekt schicken, dass null/nil ist. Ansonsten schlägt das Programm auf.
    Daher musst du überprüfen ob das Objekt einen gültigen Zustand hat, also nicht null ist. Damit man nicht jedesmal if(obj==nil) checken muss, gibts eben den ? Operator. Das ist ein Grund für optionals.

    Außerdem bauen beide Sprachen auf das Cocoa Framework auf. Als primäre Programmiersprache dient dabei das an Smalltalk angelehnte Objective-C. Sehr oft bekommt man bei Cocoa Methoden nil zurück. Zudem hat Apple das Problem, dass Objective-C und Swift "miteinander" kooperieren müssen.

    Das sind nur 2 Gründe für Optionals.

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

  • Meines Erachtens gibt es nur einen Vorteil, wenn eine Programmiersprache bei Nil-Pointern rummeckert: Wenn ein Pointer unerwartet nil ist, ist die Fehlersuche manchmal etwas schwierig.

    Andererseits bläht man durch die ständige Abfrage auf nil häufig wesentlich komplexeren Code, weswegen ich lieber den einen Nachteil in Kauf nehme. ;)
    „Meine Komplikation hatte eine Komplikation.“
  • Das hat eigentlich nichts mit statisch und dynamisch zu tun.

    Optionals sollen sicherstellen, daß ein Variable IMMER einen Wert hat.

    Beispiel:

    Folgender Code in Swift ist sicher:

    Quellcode

    1. var string: String?
    2. if string != nil {
    3. print(string)
    4. }


    Der 'gleiche' Code in Objective-C crashed:

    Quellcode

    1. NSString *string
    2. if (string != nil) {
    3. NSLog(string);
    4. }

    In Objetive-C ist der Pointer nicht initialisiert und zeigt ins Nirvana. In Swift wird sichergestellt, daß jede Variable vor dem Zugriff initialisiert ist.

    Das ist das Plus an Sicherheit.
  • tsunamix schrieb:

    Das hat eigentlich nichts mit statisch und dynamisch zu tun.

    Optionals sollen sicherstellen, daß ein Variable IMMER einen Wert hat.

    Beispiel:

    Folgender Code in Swift ist sicher:

    Quellcode

    1. var string: String?
    2. if string != nil {
    3. print(string)
    4. }

    Der 'gleiche' Code in Objective-C crashed:

    Quellcode

    1. NSString *string
    2. if (string != nil) {
    3. NSLog(string);
    4. }
    In Objetive-C ist der Pointer nicht initialisiert und zeigt ins Nirvana. In Swift wird sichergestellt, daß jede Variable vor dem Zugriff initialisiert ist.

    Das ist das Plus an Sicherheit.
    das hat aber auch nichts mit optionals zu tun.
    denn das könnte apple von heute auf morgen dem compiler einfach sagen dass nicht nur instanzvariablen defaultmäßig auf nil gesetzt werden sondern in jedem scope.
    außerdem erkennt der compiler bzw analyzer den fehler und kann ihn melden. also kein grund für optionals!
  • gritsch schrieb:

    ich habe mich mit optionals nicht befasst

    gritsch schrieb:


    das hat aber auch nichts mit optionals zu tun.denn das könnte apple von heute auf morgen dem compiler einfach sagen dass nicht nur instanzvariablen defaultmäßig auf nil gesetzt werden sondern in jedem scope.
    außerdem erkennt der compiler bzw analyzer den fehler und kann ihn melden. also kein grund für optionals!

    *seufz*

    Doch. Genau das ist der Grund hinter Optionals. Daß sichergestellt wird, daß jeder Speicher immer initialisiert ist.

    Apple kann nicht einfach den Clang-Compiler umbauen und Features implementieren, die den Sprachstandard verändern.

    Die Compiler und Analyzer sind zwar beser geworden, aber auch die können das nicht immer entdecken. Mal ehrlich. Du hast noch nie in Deinem Leben auf uninitialisierten Speicher zugegriffen?
  • tsunamix schrieb:

    *seufz*

    Doch. Genau das ist der Grund hinter Optionals. Daß sichergestellt wird, daß jeder Speicher immer initialisiert ist.

    Apple kann nicht einfach den Clang-Compiler umbauen und Features implementieren, die den Sprachstandard verändern.

    Die Compiler und Analyzer sind zwar beser geworden, aber auch die können das nicht immer entdecken. Mal ehrlich. Du hast noch nie in Deinem Leben auf uninitialisierten Speicher zugegriffen?
    klar kann apple das.
    wenn sie definieren dass variablen in obj-c 2.x oder 3.x oder was weis ich was per default mit nil/NULL/0 oder was weis ich was initialisiert werden und nicht nur die instanzvariablen, dann ist das eben so. bisheriger code läuft ja problemlos weiter (zum unterschied zu den änderungen in swift die immer wieder alten code brechen).

    Zeig mal so eine situation in der das eine maschine nicht erkennen kann!
  • macmoonshine schrieb:

    Andererseits bläht man durch die ständige Abfrage auf nil häufig wesentlich komplexeren Code, weswegen ich lieber den einen Nachteil in Kauf nehme.
    Dem stimme ich voll und ganz zu, obwohl es sich im OO Design immer wieder vermeiden ließe.

    tsunamix schrieb:

    Das hat eigentlich nichts mit statisch und dynamisch zu tun.
    Doch hat es schon. In einer dynamisch typisierten Sprache brauchst du keine Optionals. Umgekehrt kann eine statisch typisierte Programmiersprache kein nil-Messaging. Das bekommst du eine Runtime Exception "Null Reference Exception".
    Mit der von Dir erwähnten Sicherheit hast du natürlich Recht.
  • gritsch schrieb:

    tsunamix schrieb:

    *seufz*

    Doch. Genau das ist der Grund hinter Optionals. Daß sichergestellt wird, daß jeder Speicher immer initialisiert ist.

    Apple kann nicht einfach den Clang-Compiler umbauen und Features implementieren, die den Sprachstandard verändern.

    Die Compiler und Analyzer sind zwar beser geworden, aber auch die können das nicht immer entdecken. Mal ehrlich. Du hast noch nie in Deinem Leben auf uninitialisierten Speicher zugegriffen?
    klar kann apple das.wenn sie definieren dass variablen in obj-c 2.x oder 3.x oder was weis ich was per default mit nil/NULL/0 oder was weis ich was initialisiert werden und nicht nur die instanzvariablen, dann ist das eben so.
    Kurze Info für euch zwei. Das ist schon längst passiert:


    Apple Dokumentation schrieb:

    Stack Variables Are Initialized with nil
    Using ARC, strong, weak, and autoreleasing stack variables are now implicitly initialized with nil.
  • Michael schrieb:

    gritsch schrieb:

    tsunamix schrieb:

    *seufz*

    Doch. Genau das ist der Grund hinter Optionals. Daß sichergestellt wird, daß jeder Speicher immer initialisiert ist.

    Apple kann nicht einfach den Clang-Compiler umbauen und Features implementieren, die den Sprachstandard verändern.

    Die Compiler und Analyzer sind zwar beser geworden, aber auch die können das nicht immer entdecken. Mal ehrlich. Du hast noch nie in Deinem Leben auf uninitialisierten Speicher zugegriffen?
    klar kann apple das.wenn sie definieren dass variablen in obj-c 2.x oder 3.x oder was weis ich was per default mit nil/NULL/0 oder was weis ich was initialisiert werden und nicht nur die instanzvariablen, dann ist das eben so.
    Kurze Info für euch zwei. Das ist schon längst passiert:

    Apple Dokumentation schrieb:

    Stack Variables Are Initialized with nil
    Using ARC, strong, weak, and autoreleasing stack variables are now implicitly initialized with nil.


    hatte ich doch irgendwie im kopf. war mir aber nicht sicher ob es irgend ein draft war...

    aber ist ja auch komplett egal ;)
  • Ein weiterer Vorteil von Optionals ist, dass es sich z.B. bei folgendem Code:

    Quellcode

    1. var viewA: UIView?
    2. und
    3. var viewB: UIView
    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.
  • Markus Müller schrieb:

    Ein weiterer Vorteil von Optionals ist, dass es sich z.B. bei folgendem Code:

    Quellcode

    1. var viewA: UIView?
    2. und
    3. var viewB: UIView
    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.
    ebenso das hat nichts mit optionals zu tun!
  • gritsch schrieb:

    Markus Müller schrieb:

    Ein weiterer Vorteil von Optionals ist, dass es sich z.B. bei folgendem Code:

    Quellcode

    1. var viewA: UIView?
    2. und
    3. var viewB: UIView
    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.
    ebenso das hat nichts mit optionals zu tun!
    Kannst Du näher ausführen, was Du meinst?
  • Markus Müller schrieb:

    gritsch schrieb:

    Markus Müller schrieb:

    Ein weiterer Vorteil von Optionals ist, dass es sich z.B. bei folgendem Code:

    Quellcode

    1. var viewA: UIView?
    2. und
    3. var viewB: UIView
    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.
    ebenso das hat nichts mit optionals zu tun!
    Kannst Du näher ausführen, was Du meinst?
    dass statische vs dynamischer typisierung deines beispiels nichts mit den optionals zu tun hat um die es hier im thread eigentlich geht.