Objec. C oder Swift(2) in Verbindung mit Cocoa?

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

  • hirnwunde schrieb:

    Auch wenn ich die Coalesc-Funktionen noch nicht angefasst habe, klingt das Prinzip, das Nicolaj dort anspricht, doch recht Realitätsfern.
    Inwiefern? Eine coalesce-Funktion in Swift ist Dank des eingebauten ??-Operators nicht notwendig. Trotzdem hat er ein damit ein sehr gutes Beispiel für einen Vortrag gefunden. Die Funkton ist so einfach, dass sie jeder Zuhörer sofort versteht, und er konnte damit genau ein Problem (Kombination von Generics und Optionals) illustrieren.

    Was findest du realitätsfern?
    „Meine Komplikation hatte eine Komplikation.“

  • hirnwunde schrieb:

    Für jemanden, der nicht dem Vortag lauschen konnte (und auch vor dem April 2016 (die 2019 seh ich mal als Tippfehler an) nicht die Möglichkeit hat) ist das nur schwer nachzuvollziehen.
    Das ist ja genau der Sinn des Beispiels gewesen. Er hat damit gezeigt, wie ein einfaches Problem schnell zu unerwarteten Ergebnissen führen kann. das Beispiel hat (frei nach meinem Gedächnis) ungefähr so ausgesehen:

    Quellcode

    1. func coalesce<T>(a: T?, _ b: T) -> T {
    2. if let r = a {
    3. return r
    4. }
    5. else {
    6. return b
    7. }
    8. }
    10. var a: Int?
    11. let b: Int? = 2
    12. let c = coalesce(a, b)
    13. print("\(c)")
    Alles anzeigen
    Preisfrage: Welchen Typ und Wert hat c?

    hirnwunde schrieb:

    Das klingt sehr abstrakt.
    Kommen wir nochmal zu der Aussage aus meinem ersten Beitrag... ;)
    „Meine Komplikation hatte eine Komplikation.“

  • hirnwunde schrieb:

    macmoonshine schrieb:

    if let r = a {

    Mein Verständnis sagt mir, das es gar nicht zu einem else kommen kann, da eine Zuweisung, wie sie hier ja stattfindet, immer true ergeben sollte.
    Aber da spiegelt sich auch mein Unwissen wieder. Ich verstehe ja nicht mal den Rumpf der Funktion.

    Und eben das ist falsch, weil a ein Optional ist.
    Die Zuweisung let r = a ist nur dann erfolgreich, wenn a ungleich nil ist.
    Ansonsten würde es zu Inkonsistenz führen, da r ungleich nil sein muss.

    Das zum Thema 'bekannt' und 'leichter zu lesen'…

    Ich denke nicht, dass ich den Code richtig verstehe, aber ich versuch's trotzdem.
    a wird als Optional erwartet, b nicht.

    Es werden zwei Optionals übergeben, wodurch a ein Optional auf ein leeres Optional vom Typ Integer ist, b ein Optional auf einen Integer mit Wert 2 und das Resultat ein Optional auf einen Integer sein sollte.
    (Scheiß generische Funktionen, blöde. Die taugten schon in ANSI C++ 99 nix…)

    Nun ist a einmal aufgelöst eben nicht nil sondern ein Optional auf nil.
    Die Zuweisung müsste also auf r:Int? auflösen und damit funktionieren.

    Ergo kommt ein Optional Integer mit Wert nil zurück.
    (Nur einfaches Optional, da ja das einmalig aufgelöste r zurückgegeben wird und nicht das doppelt optionale a)

    Kann aber auch totaler Schwachsinn sein.
    Ist halt einer der vielen Vorteile bei leicht verständlichem und lesbarem Code. :D

    (Ich halte das übrigens nicht für ein Swift Problem, sondern für ein Swift->Cocoa Problem, wie so ziemlich alle Probleme in Swift. Deshalb kann ich die Sprache durchaus empfehlen, aber nicht in Verbindung mit der App Entwicklung.)
    «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

  • hirnwunde schrieb:

    Mein Verständnis sagt mir, das es gar nicht zu einem else kommen kann, da eine Zuweisung, wie sie hier ja stattfindet, immer true ergeben sollte.
    Im Prinzip ist das wie in Ur-C: if(r = a) { ist wahr, wenn a nicht 0 ist. Das ist eine Kurzform von if((r = a) != 0) {. In (Objective-)C hätte ich die Bedingung auch umgedreht:

    Quellcode

    1. if(a == nil) {
    2. return b;
    3. }
    4. else {
    5. return a;
    6. }
    Im Gegensatz zu Swift funktioniert das auch. Die coalesce-Funktion liefert dort nämlich immer nil unabhängig von der Eingabe.
    „Meine Komplikation hatte eine Komplikation.“

  • Ist das mit den Optionals aber nicht doch ein bisschen komplizierter?

    Es ist ja nun nicht so, dass die Methode in Objective–C sinngemäß so aussieht:
    - (void *)coalesce:(void *)a :(void *)b

    Sondern eher so:
    - (void *)coalesce:(void * *)a :(void *)b

    In dem Fall ist ja a != nil sondern erst *a == nil.
    Insofern dürfte auch in Objective-C der Vergleich if( a == nil ) { niemals greifen.

    Quellcode

    1. NSLog( @"Testing" );
    2. void * test = nil;
    3. void * tast = &test;
    5. if( tast == nil ) {
    6. NSLog( @"nil" );
    7. }
    8. else {
    9. NSLog( @"not" );
    10. }
    2015-10-30 17:13:42.477 Dummy[28138:800315] Testing
    2015-10-30 17:13:42.477 Dummy[28138:800315] not
    «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

  • Ungefähr da liegt das Problem ... in Swift, in der Pointer in Optionals verpackt sind. In Objective-C hast und brauchst du diese Verpackung nicht, weswegen du beruhigt die erste Deklaration verwenden darfst. Du willst ja schließlich einen Anwendungsfall implementieren, und kein Problem nachstellen. ;)
    „Meine Komplikation hatte eine Komplikation.“

  • t-no schrieb:

    Wenn der Anfangsbeitrag nicht so lang wäre, hätte ich darauf gewettet, das es ein Troll-Versuch ist ;)

    Wie du schon bemerkt hast sind die Contra-Swift Argumente in der Regel sehr subjektiv, und erfahrungsgemäß wird es nicht lange dauern, bis der Thread vor Unfug überläuft...
    Objective-C hat auch eine lange Geschichte hinter sich, und du wirst noch genug Beispielcode finden, der heute nicht mehr zeitgemäß ist. Bei Swift ist imho die Zeit der großen Umbrüche vorbei, und ich rechne nicht damit, dass die nächste Version fundamentale Inkompatibilitäten verursacht.
    Ich glaube auch, dass deine Einschätzung zur zukünftigen Verbreitung falsch ist:
    Die Pro-Objective-C Fraktion arbeitet fast ausschließlich schon sehr lange mit der Sprache, und viele Mitglieder haben "Investitionen", die durch Swift an Wert verlieren. Diese Gruppe ist aber die Minderheit - die Mehrheit der Entwickler sind erst sehr spät auf den Zug aufgesprungen und haben vorher mit Sprachen gearbeitet, die viel näher an Swift als an Objective-C liegen; bei der Anzahl an Leuten, die iOS-Entwicklung an sich cool finden, aber die Sprache gehasst haben, wird es nicht lange dauern, bis sich die Verteilung umkehrt.

    Mein Rat daher:
    Nimm' die Sprache, die dir sympathischer ist.
    Den Trollversuch unternimmst doch du. Ebenso das Anladen von Unfug in diesem Thread..

    Dass Templates eine weitere Indirekten darstellen, also verkomplizieren,

    * ist weder Unfug
    * noch subjektiv
    * noch hat es etwas mit bestehenden Code zu tun

    Dass Overloading und Type-Inference zu nicht durchschaubaren Ergebnissen führen,

    * ist weder Unfug
    * noch subjektiv
    * noch hat es etwas mit bestehenden Code zu tun

    Dass Operatoren anstelle von Namen weniger selbsterklärend sind,

    * ist weder Unfug
    * noch subjektiv
    * noch hat es etwas mit funktionierendem Code zu tun

    Dass Swift zahlreiche Konstruktute einführt, die es vorher in verbreiteten Programmiersprachen nicht gegeneben hat, jedenfalls nicht in dieser Kombination
    * ist weder Unfug
    * noch subjektiv
    * noch hat es etwas mit bestehendem Code zu tun.

    Soll ich weiter machen?
    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"?

  • hirnwunde schrieb:

    Michael schrieb:

    Ein Swift Optional sieht so aus:
    Ok ... var foo: String? ist für mein Verständnis eine initialisierte Variable ohne Wert. Scheinbar habe ich Swift's Optionals nicht verstanden. Nochmal die Doku durchlesen gehen.
    Das kann nicht sein. Optionals sind einfach.
    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"?

  • zerm schrieb:

    Marco Feltmann schrieb:

    Echt, wenn Swift die Lösung sein sollte möchte ich gern mein Problem zurück.
    Da schlag ich mich doch eher auf zerms Seite und steig' auf C++ um!
    Wir haben Kekse und heisse Milch!
    Da wäre ich sogar dabei. C++ ist wenigstens konsequent kompliziert, während Swift hirnrissig kompliziert ist.
    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:

    zerm schrieb:

    Marco Feltmann schrieb:

    Echt, wenn Swift die Lösung sein sollte möchte ich gern mein Problem zurück.
    Da schlag ich mich doch eher auf zerms Seite und steig' auf C++ um!
    Wir haben Kekse und heisse Milch!
    Da wäre ich sogar dabei. C++ ist wenigstens konsequent kompliziert, während Swift hirnrissig kompliziert ist.
    Ja, Swift ist wirklich die Episode I unter den Programmiersprachen, und Optionals sind die Jar Jar Binks unter den Konstrukten: Viel Gelaber, überhaupt nicht komisch und absolut überflüssig ;)
    „Meine Komplikation hatte eine Komplikation.“