Andy Matuschak im Debug-Podcast

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

  • macmoonshine schrieb:

    Bei diesem Swift-Hurra-Patriotismus fällt meines Erachtens auch leider viel zu häufig unter den Tisch, dass Apple damit auch einige einzigartige Features streicht; beispielsweise Method-Swizzling. Vor einigen Jahren konnte man viele Apple-Tools noch mit Plugins erweitern. Das ist jetzt eher selten, und mit jeder neuen Version funktionieren alte Plugins nicht mehr.

    Ich bin mir nicht sicher, ob ich Method Swizzling hinterhertrauern soll. Ist ungefähr so wie eine Affäre: Manchmal ungemein reizvoll sich auszumalen, was man für aufregende Dinge anstellen könnte. Wenn man sich aber wirklich dazu hinreißen lässt und nicht höllisch aufpasst, kann das Ganze ganz schnell zum Albtraum werden. Und insgeheim hatte man eh die ganze Zeit das Gefühl, dass es nicht richtig ist.
    Multigrad - 360°-Produktfotografie für den Mac
  • Naja, grundsätzlich sind die Konzepte von Swift und Objective-C aber schon gravierend anders.

    Hat Swift Categories für Swift Objekte? Nein. Braucht es die? Nein. Swift kann das Gleiche mit Funktionen erreichen.
    Dann heißt es halt nicht mehr

    Quellcode

    1. if( [creationError isFileNotFoundError] ) {…}

    sondern

    Quellcode

    1. if( isFileNotFoundError( creationError ) ) {…}

    Eigentlich egal.

    Hat Swift KVO für Swift Objekte? Nein. Braucht es die? Nein. Dank statischer Typisierung reichen da die PropertyObserver.
    Statt eines Keypaths verketten man dann halt PropertyObserver. Nicht schön, geht aber.

    Hat Objective-C Method-Swizzling? Jein. Die Objective-C Runtime hat Method-Swizzling, welche sich prima über C-Funktionen aufrufen lässt. (Siehe Signaturen: const char * object_getClassName ( id obj );, IMP class_replaceMethod ( Class cls, SEL name, IMP imp, const char *types );, etc.pp.)
    Ist nützlich, beispielsweise für KVO. Was man bei Property Observation aber nicht zwingend benötigt.

    Hat so was von Kartoffelplfanzen und Kirschbäumen:
    'Kartoffelplanzen wachsen in Bodennähe, man kommt also leicht ran. Ihre Knollen sind verhältnismäßig groß, man hat also viel davon.' vs. 'Kirschbäume haben den Vorteil, dass man sich den Rücken beim Ernten nicht ruiniert. Außerdem lassen sich die Kirschen ohne weitere Arbeiten einfach so verzehren.' ;)
    «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
  • Davon ausgehend, dass Objekt A Objekt B als Property hat: indem es sich über Callbacks informieren lässt.

    Davon ausgehend, dass nicht: Gar nicht.
    (Ich habe nie gesagt, dass es 'genau so wie KVO' geht. Geht es auch nicht. Ist aber für viele Fälle ausreichend.)
    «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
  • mattik schrieb:

    Ich bin mir nicht sicher, ob ich Method Swizzling hinterhertrauern soll.

    Das ist sicherlich kein 08/15-Instrument, das man täglich einsetzen sollte. Es war aber eines der Features, die ich zu Beginn am faszinierendsten fand. Da konnte man gewisse Bugs (in WebObjects) beheben, ohne auf langwierige Updates von Apple warten zu müssen. Mir geht es auch um etwas anderes: Mit Swift fallen, wie z. B. auch beim App-Store, einige alt-bekannte Features klammheimlich unter den Tisch. Mit Swift übernimmt Apple die Kontrolle an Stellen, die sie schon mal abgegeben hatten.

    Michael schrieb:

    Dazu brauchst du aber entweder den Quellcode für Objekt B oder musst eine Subklasse erstellen. Und immer wenn in deinem Projekt ein Observer hinzu kommt oder wegfällt musst du Objekt B anfassen.

    KVO kommt damit ungefähr auf den Stand von Java, und ist damit - hurra - tot. :(
    „Meine Komplikation hatte eine Komplikation.“
  • kmr schrieb:

    dasdom schrieb:


    @andy_matuschak : Because Obj-c is going to die


    Daran zweifelt doch niemand ernsthaft, oder?

    Hier!

    Übrigens wäre es nicht nur die logische, sondern zwingende Folge, Cocoa auch sterben zu lassen.
    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"?
  • macmoonshine schrieb:

    mattik schrieb:
    Ich bin mir nicht sicher, ob ich Method Swizzling hinterhertrauern soll.

    Das ist sicherlich kein 08/15-Instrument, das man täglich einsetzen sollte. Es war aber eines der Features, die ich zu Beginn am faszinierendsten fand. Da konnte man gewisse Bugs (in WebObjects) beheben, ohne auf langwierige Updates von Apple warten zu müssen. Mir geht es auch um etwas anderes: Mit Swift fallen, wie z. B. auch beim App-Store, einige alt-bekannte Features klammheimlich unter den Tisch. Mit Swift übernimmt Apple die Kontrolle an Stellen, die sie schon mal abgegeben hatten.

    Stimmt natürlich, cool ist das allemal und man kann es bestimmt auch hier und da sinnvoll einsetzen - wobei vieles davon, auch das Patchen von Bugs, eher dirty hack ist. Ich kann Apple an der Stelle sogar etwas verstehen: Eine so offene Runtime mit derart dynamischen Möglichkeiten ist Wartungs-, Sicherheits- und optimierungstechnisch halt schwierig. Meinetwegen können sie gerne einiges von der Runtime zur Compiletime schieben und ich nehme auch hier und da Abstriche der sprachlichen Möglichkeiten in Kauf, wenn sie dadurch Stabilität und Performanz merklich verbessern können. Bei Apples Kontrollwahn hätte ich noch vieles davor auf meiner Liste, ganz oben diese immer noch unerträgliche Sandbox.

    Ich bilde mir darüber konkretere Vorurteile, wenn Swift irgendwann mal produktionsreif ist - also nicht in der näheren Zukunft, bis dahin bleibt ObjC für mich das Mittel der Wahl. Mich ärgert viel mehr an der ganzen Sache, dass Apple auch davor noch genügend offene Baustellen hatte. Davon hätte man ja erstmal einige fertig machen können, bevor man sich eine neue Sprache an die Backe bindet.
    Multigrad - 360°-Produktfotografie für den Mac
  • Zum Thema KVO: Anfangs fand ich das auch genial und es durchzieht Cocoa ja an vielen Stellen (Stichwort Bindings). Allerdings denke ich, dass Apple da bewusst eine Abkehr vorgenommen hat. Mittels KVO hat man zwar nicht so eine enge Kopplung, aber es bleibt eine Kopplung. Die ist nicht explizit und leicht zu übersehen, wenn man Code liest (ebenso wie die oft erst zur Laufzeit zu entdeckenden KVC-Kopplungen mit Keypfaden). Und mit dem Trend hin zu immutable models/structs in Swift ist KVO auch nicht mehr so notwendig. Ausserdem tun sich durch die "Magie" von KVO mit threading diverse Fallstricke auf, die nicht gleich ersichtlich sind. Und Sachen wie Method Swizzling braucht man ja dann doch eher selten.

    Ich finde es gut, dass sie da eine neue Richtung einschlagen und finde diese nicht per se schlecht, auch wenn man über die Durchführung derselben trefflich streiten kann (Stichwort SourceKit-Crashes :)
  • Marco Feltmann schrieb:


    Hat Swift Categories für Swift Objekte? Nein. Braucht es die? Nein. Swift kann das Gleiche mit Funktionen erreichen.
    Dann heißt es halt nicht mehr

    Quellcode

    1. if( [creationError isFileNotFoundError] ) {…}

    sondern

    Quellcode

    1. if( isFileNotFoundError( creationError ) ) {…}

    Eigentlich egal.

    ​Argh. D.h. ich kann keine Bundles mehr dazuladen, die mittels Category unterschiedliche Dinge in einer Hauptklasse ergänzen. Außer ich stelle alles auf Funktionen um?
    M.E. sind Categories eine der elegantesten Lösungen von Obj-C 1.0 und dienen der besseren Strukturierung von Code.
    Natürlich kann man die mißbrauchen und missverstehen, also falsch anwenden.
    Klar, Obj-C 2 macht das durch explizite Protokolle häufiger überflüssig. Aber wenn man z.B. NSData um eine Methode erweitern will und nicht eine NSDataWithMyExtension einführen will, sind Categories einfach unschlagbar. Sie verstecken die Implementierung (halt auf 2 Files), aber vor dem Anwender. Wenn man das nur noch über Funktionen erweitern kann, dann frage ich mich ein bisschen warum man nicht gleich mit

    Quellcode

    1. objc_msgSend(object, @selector(), ...)
    arbeitet :)
  • hns schrieb:

    Wenn man das nur noch über Funktionen erweitern kann, dann frage ich mich ein bisschen warum man nicht gleich mit objc_msgSend(object, @selector(), ...) arbeitet

    Weil Swift so übermegageil statisch ist, dass es das nicht kann? ;)

    Sind halt so Details.
    Optionale Protokollmethoden fallen weg, weil sich nicht via [obj respondsToSelector:] das Vorhandensein einer solchen optionalen Methode prüfen lässt.
    (Ein Detail, das mich schon bei Java ankotzt… Interfaces? Geht doch wo euer Haus wohnt!)

    Ich bin mir jedenfalls sicher, dass Objective-C sterben und Swift die Nachfolge antreten wird.
    Aber ich hoffe und bete, dass ich mich damit grundlegend irre und Swift nur ein wenig Ablenkung für ein im Geheimen zusammengeschustertes 'Objective-C Done Right' ist. ;)
    «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
  • Marco Feltmann schrieb:

    Optionale Protokollmethoden fallen weg, weil sich nicht via [obj respondsToSelector:] das Vorhandensein einer solchen optionalen Methode prüfen lässt.

    Das kann man in Swift doch über den Universal-Operator „?“ machen, z. B. (aus der Apple-Doku):

    Quellcode

    1. func increment() {
    2. if let amount = dataSource?.incrementForCount?(count) {
    3. count += amount
    4. } else if let amount = dataSource?.fixedIncrement? {
    5. count += amount
    6. }
    7. }

    Dabei ist incrementForCount eine optionale Methode eines Protokolls.
    „Meine Komplikation hatte eine Komplikation.“