Swift-evolution

  • In irgendeinem WWDC Video wurde über die Initializer Thematik gesprochen.
    Wenn ich mich recht erinnere, soll der Initializer Mechanismus in Swift verhindern, dass man durch Überschreiben von Methoden der Superklasse auf nicht initialisierte Variablen zugreifen kann.

    Nehmen wir an SuperClass ruft in seinem init eine Methode setupAllTheThings auf.
    Nun überschreiben wir setupAllTheThings in SubClass und greifen darin auf Instanzvariablen unserer Subclass zu.

    Würden diese erst nach dem Super call zu Init gesetzt werden, hätten wir nil Werte bei non-Optionals.

    Ohne groß drüber nachzudenken stellt sich die Frage ob die "Keine Methodenaufrufe vor Ende des Inits" Regel nicht gereicht hätte um das zu verhindern.

  • Thyraz schrieb:

    Wenn ich mich recht erinnere, soll der Initializer Mechanismus in Swift verhindern, dass man durch Überschreiben von Methoden der Superklasse auf nicht initialisierte Variablen zugreifen kann.
    Stimmt, das hatte ich auch irgendwo gesehen. Wieder eine weitere Einschränkung, die eine Fehlerquelle verhindert, die so gut wie nie vorkommt.

    Und wenn sie tatsächlich doch mal vorkommt, hat der Programmierer danach sicherlich gelernt, was Initialisierung bedeutet. ;)
    „Meine Komplikation hatte eine Komplikation.“

  • MCDan schrieb:

    Ein Argument von Apple für Swift ist ja auch die höhere Geschwindigkeit bei der Ausführung. Ist die Objective-C Runtime denn wirklich schon komplett ausgereizt und geht es daher nicht schneller?

    Evtl. sollte Apple einfach mal etwas mehr Energie in die weitere Optimierung der Objective-C Runtime stecken. Dies würde dann ja auch die Ausführung von bestehendem Code beschleunigen.

    Ist die Objective-C Runtime eigentlich öffentlich oder liegt die verschlossen bei Apple?
    Also an der Runtime kann es nicht liegen. Mein alter Single-Core PowerPC MacMini mit OS X 10.5.8 und langsamer Platte fühlt sich i.d.R. flüssiger zu bedienen an als alles Modere. Vor allem wenn man keine SSD hat.

    Die Runtime ist soweit ich öffentlich: opensource.apple.com/source/ob….1/runtime/objc-runtime.m

  • macmoonshine schrieb:

    Quellcode

    1. class A {
    2. init(i: Int) {
    3. print("A: \(i)")
    4. }
    5. }
    7. class B: A {
    8. let l: Int
    9. var v: Int
    11. init() {
    12. l = 1
    13. v = 2
    14. super.init(i: 3)
    15. }
    16. }
    Alles anzeigen
    B kann deshalb beispielsweise l niemals in Abhängigkeit von A setzen. :(

    Das 'niemals' ist so nicht ganz richtig. Natürlich geht das, aber dazu muß l als var deklariert sein. Weil wir das in einem anderen Thread hatten. Das wäre dann einer der seltenen Fälle, in denen es Sinn ergeben kann, eine Membervariable als explicitly unwrapped optional zu deklarieren.

  • tsunamix schrieb:

    Das 'niemals' ist so nicht ganz richtig.
    Das niemals ist schon richtig. MIt var deklarierte Variablen kannst du ändern, wann du willst. Mit let deklarierte hingegen nur einmal initialisieren. Und wenn man Klassen für nicht veränderliche Objekte erstellen möchte, sollte man let bevorzugen. In diesem Zusammenhang ist var also eher uninteressant.

    Abgesehen davon musst du auch v in dem Beispiel immer vor dem super-Aufruf initialisieren, ansonsten gibt's ein error: property 'self.v' not initialized at super.init call
    „Meine Komplikation hatte eine Komplikation.“

  • MCDan schrieb:

    Ein Argument von Apple für Swift ist ja auch die höhere Geschwindigkeit bei der Ausführung. Ist die Objective-C Runtime denn wirklich schon komplett ausgereizt und geht es daher nicht schneller?

    Evtl. sollte Apple einfach mal etwas mehr Energie in die weitere Optimierung der Objective-C Runtime stecken. Dies würde dann ja auch die Ausführung von bestehendem Code beschleunigen.

    Ist die Objective-C Runtime eigentlich öffentlich oder liegt die verschlossen bei Apple?
    Da zuletzt ziemlich an dem RTE optimiert (64-Bit RTE) wurde, gehe ich davon aus, dass das ausgereizt ist. Vielleicht kann man noch etwas herausholen, aber viel wird das nicht sein.

    Es gab mal ne Statistik vor geraumer Zeit, dass eine Objective-C-Message etwa 150 % bis 200 % eines C-Calls benötigt. Also fast doppelt so langsam. (War vor der Optimierung.) Das überraschte mich in zweierlei Hinsicht:

    * Ich hielt es für erstaunlich schnell, wenn man bedenkt, dass man einen Look-Up machen muss. Andererseits muss man ja bedenken, dass der eigentliche Aufruf nur einen Bruchteil von allem ausmacht, weil Stackframes gebaut werden müssen, Werte dorthin platziert werden müssen, retains unter Umständen gemacht werden müssen (ARC gab es damals aber noch nicht) usw.

    * Ich hielt es für erstaunlich langsam, wenn man bedenkt, dass man das fast in jedem Statement hat. Müsste sich also extrem auf die Ausführungszeit auswirken, was mir nie praktisch auffiel.

    Aber insgesamt ist es eben so, dass der Dispatch ein Teil des Nachrichtenversandes ist und der Nachrichtenversand ein Teil der Programmausführung. Ich lernte dann eben: Vergiss es, es ist unwichtig.

    Das RTE ist Open-Source. Die letzten Änderungen stammen von 2012, wenn ich das richtig sehe.
    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"?

  • tsunamix schrieb:

    Amin Negm-Awad schrieb:

    ja, aber dann kommt Objective-C mit runden Klammern heraus.
    Diesen Ansatz gab es schon mal, und zwar von Apple höchst persönlich. :D
    "Modern" Objective-C syntax (1997)
    Nein, das wäre die kranke Syntax von Swift, allerdings nicht ganz so schlimm. (Wieder so ein Beispiel, in dem etwas Funktionierendes kaputt formalisiert wurde.) Aber, dass sich das nicht durchgesetzt hat, sagt auch etwas aus. Wieso wollte das nur niemand?

    Ich meinte eher ((MyClass alloc) init) oder exemplarischer: (myObject doSomethingWith:(person name))

    Von Weiher stammt der Vorschlag, ganz auf Klammern zu verzichten: MyClass alloc init oder eben myObject doSomethingWith:person name
    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"?

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Amin Negm-Awad ()

  • Swift 2.2 Release Process

    Mit Swift 2.2 ist also gegen März/ Mai dieses Jahres zu rechnen.
    Ich finde es ja eine positive Nebenerscheinung dieser OS-Geschichte, daß man in diesem Punkt nicht mehr auf der WWDC mit einem Kaninchen aus dem Hut überrascht wird, sondern sich lange vorher vorab informieren kann...

    Eine weitere Nebenerscheinung ist es, daß man auf den Repos so manche Perle entdecken kann:
    Commonly Rejected Changes:
    "Swift is designed to feel like a member of the C family of languages. Switching keywords away from C precedent without strong motivation is a non-goal."

    Ah ja... Wie war das noch mit do while -> repeat while und for ;;?

  • macmoonshine schrieb:

    tsunamix schrieb:

    Ah, OK. Ich denke das Changelog komt dem am nächsten.
    Nein, das beschreibt ja nur bereits vollzogene Änderungen. Mich interessieren aber die geplanten Änderungen.
    Da müßtest Du Dich wahrscheinlich durch das Swift-evolution Repo durchklicken und gucken, was auf 2.2 zutrifft. In der Readme finden sich noch zwei Punkte, die für 2.2 angenommen, aber, soweit ich sehe, noch nicht implementiert sind.

  • tsunamix schrieb:

    Da müßtest Du Dich wahrscheinlich durch das Swift-evolution Repo durchklicken und gucken, was auf 2.2 zutrifft. In der Readme finden sich noch zwei Punkte, die für 2.2 angenommen, aber, soweit ich sehe, noch nicht implementiert sind.
    Wahrscheinlich bekomme ich da aber auch nur die halbe Information.

    Wikipedia schrieb:

    Ein Projekt ist ein zielgerichtetes, einmaliges Vorhaben, das aus einem Satz von abgestimmten, gelenkten Tätigkeiten mit Anfangs- und Endtermin besteht und durchgeführt wird, um unter Berücksichtigung von Zwängen bezüglich Zeit, Ressourcen (zum Beispiel Geld bzw. Kosten, Produktions- und Arbeitsbedingungen, Personal) und Qualität ein Ziel zu erreichen.
    +scnr+
    „Meine Komplikation hatte eine Komplikation.“