Popularität von Swift ?

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

  • MCDan schrieb:

    WernerB schrieb:

    Amin Negm-Awad schrieb:

    Und natürlich ist bei Apple intern fast alles Objective-C. Die wissen schließlich was Swift und Obejctive-C sind und können. Wieso sollten sie also Swift nehmen? Das ergäbe doch gar keinen Sinn.
    Apple wäre doch auch mit dem Klammerbeutel gepudert, eine Code-Basis umzuschreiben, die in Teilen 30 Lenze auf dem Buckel hat und somit ausgereift ist. Und (massive) Geschwindigkeitsvorteile von Swift scheinen auch nicht zu existieren.
    Ich meine ich hätte mal irgendwo gelesen, dass der aktuelle Finder jetzt mit Swift programmiert wurde. Kann mich aber auch täuschen. Evtl. Vorteile diesbezüglich beim Finder sehe ich nicht. Eher finde ich die Anzeige eines Verzeichnisse als Liste (Outline View) unschön, da die Verzeichnisse erst nach und nach aufgeklappt werden und somit die erste Anzeige lange dauert und sehr unruhig ist. Ich meine dies sah vorher besser aus.
    Gut, das haben sie ja beim Code Editor von Xcode 9 auch gemacht. Interessant wäre nur, ob sie weiterhin NS*-Klassen benutzen oder die bereits auftauchenden Analoga in Swift. Ersteres hiesse für mich, gehoppst wie gesprungen.
  • WernerB schrieb:

    Amin Negm-Awad schrieb:

    Und natürlich ist bei Apple intern fast alles Objective-C. Die wissen schließlich was Swift und Obejctive-C sind und können. Wieso sollten sie also Swift nehmen? Das ergäbe doch gar keinen Sinn.
    Apple wäre doch auch mit dem Klammerbeutel gepudert, eine Code-Basis umzuschreiben, die in Teilen 30 Lenze auf dem Buckel hat und somit ausgereift ist. Und (massive) Geschwindigkeitsvorteile von Swift scheinen auch nicht zu existieren.
    Na, ja, es ging ja jetzt darum, was Apple derzeit noch macht. Und das ist dann ja häufig neu.

    Aber davon abgesehen kannst du etwa in Responder-Chain in Swift (ohne Objective-C/Objective-C-RTE) gar nicht implementieren. Insofern stellt sich doch gar nicht die Frage, wie viel Aufwand es wäre. Der Aufwand wäre 0 oder unendlich, weil es eben nicht geht.
    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"?
  • MCDan schrieb:

    Ups, habe ich bisher noch gar nicht verwendet.

    Ist ja auch nur für den Compiler interessant, oder wird diese Info auch zur Laufzeit verwendet/geprüft?
    Sie sind nur für den Swift-Compiler interessant.

    Ob der Objective-C-Compiler das auch prüft, weiß ich ehrlich gesagt gar nicht. Mir war der Aufwand dann doch zu groß, weil es ja nur Sinn macht, wenn du das massiv durch die gesamte Source durchziehst. (Deshalb muss es ja auch in Objective-C eingebaut werden. Dieses Feature war als Swift-only ja völlig sinnbefreit.) Dann ist das aber doch recht viel Arbeit, um beim Compilieren einen Fehler zu entdecken, den ich ohnehin 20 Sekunden später bemerkt hätte. (Wobei natürlich ein 20-Sekunden-Turn-Around bei Swift ein Wunschtraum ist.)

    Auch wenn "Attempted-to-insert-Nil-Argument"-Fehler auch in der Wirklichkeit doch hin und wieder vorkommen, ist der Aufwand enorm,
    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:

    Aber davon abgesehen kannst du etwa in Responder-Chain in Swift (ohne Objective-C/Objective-C-RTE) gar nicht implementieren. Insofern stellt sich doch gar nicht die Frage, wie viel Aufwand es wäre. Der Aufwand wäre 0 oder unendlich, weil es eben nicht geht.

    Warum sollte dies in Swift nicht gehen? Wenn ich mir die Bugs bezügl. contentViewController unter macOS 10.10 bis 10.12 anschaue, kann dies mit Swift auch nicht viel schlechter werden. :D
  • MCDan schrieb:

    Amin Negm-Awad schrieb:

    Aber davon abgesehen kannst du etwa in Responder-Chain in Swift (ohne Objective-C/Objective-C-RTE) gar nicht implementieren. Insofern stellt sich doch gar nicht die Frage, wie viel Aufwand es wäre. Der Aufwand wäre 0 oder unendlich, weil es eben nicht geht.
    Warum sollte dies in Swift nicht gehen? Wenn ich mir die Bugs bezügl. contentViewController unter macOS 10.10 bis 10.12 anschaue, kann dies mit Swift auch nicht viel schlechter werden. :D
    Weil die Responder-Chain voraussetzt, dass eine dem Programmierer des Frameworks unbekannte Actionmessage zur Laufzeit aus einem Nib geladen wurde und jetzt herausgefunden werden muss, welches Objekt in der Responder-Chain darauf antworten möchte. Das ist zur Übersetzungszeit nicht entscheidbar, sondern muss durch dynamischen Nachrichtenversand gelöst werden. Den kennt Swift zwar – weil es Objective-C und die Objective-C-RTE verwenden kann.

    Oder anders: Wenn du Objective-C und die Objective-C-RTE herausschmeißt, gäbe es keine Möglichkeit in Swift, aus einem Klartext zur Laufzeit einen Call zu machen. Das widerspricht ja auch dem Grundkonzept von Swift.

    Funktionieren kann das allenfalls mit vom Framework vorgegebenen Messages, da diese das Framework zur Übersetzungszeit kennt.

    Dises Problem tauscht freilich auch bei anderen statisch typsierenden, früh bindenden Programmiersprachen auf. Und sie alle musste für die Programmierung von ereignisgetriebenen Programmen ("GUI-Apps") einen außerhalb des eigentlichen Konzeptes stehende Erweiterung vorsehen. In C++ sind das Signals und Slots (AFAIK inzwischen Sprachstandard), in C# Delegates.

    Mit einzelnen Bugs hat das freilich nichts zu tun. Es geht hier um die konzeptionelle Grundentscheidung.
    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 1 mal editiert, zuletzt von Amin Negm-Awad ()

  • Klar, erst denken dann schreiben. Da ich schon so lange in Objective-C programmiere, war es mir gar nicht direkt ersichtlich, dass es ein respondsToSelector: in anderen Sprachen wie z.B. Swift gar nicht gibt. :D

    In Swift müsste man dies dann z.B. mit einem Protocol lösen, bei dem die Methode einen Rückgabewert hat. Ist jetzt sicherlich nicht so schön wie in Objective-C, ginge aber auch.
  • MCDan schrieb:

    Klar, erst denken dann schreiben. Da ich schon so lange in Objective-C programmiere, war es mir gar nicht direkt ersichtlich, dass es ein respondsToSelector: in anderen Sprachen wie z.B. Swift gar nicht gibt. :D

    In Swift müsste man dies dann z.B. mit einem Protocol lösen, bei dem die Methode einen Rückgabewert hat. Ist jetzt sicherlich nicht so schön wie in Objective-C, ginge aber auch.
    Nö, geht immer noch nicht. Dann weiß also die Responder-Chain, dass das Objekt auf die Nachricht hört. Und wie macht man jetzt ohne dynamische Bindung aus dem Text im Nib "myGreatCustomMethod:" ohne Objective-C-RTE einen Call? Und woher kennt überhaupt die Responder-Chain die Methode/Funktion, damit man sie ausführen kann? Was steht denn im Framework an der Stelle? if( [responder implements:…] ) { // un nu? }

    Dazu brauche ich mindestens die Fähigkeit, aus einem Text einen Selector zu machen und dann diesen – zur Laufzeit erst feststellbaren – Selector für einen dynamischen Dispatch zu nutzen. Ei, da ist wieder das dynamisch.

    Ich habe vielleicht zu wenig Ahnung von Swift, um einen Trick zu übersehen. Aber es geht ja eigentlich auch um das Grundkonzept, nicht eine überraschende Wendung. Wi dem auch sei, ich habe schon häufiger die Diskussion geführt:

    X: "Der Aufwand lohnt sich nicht für Apple."
    Amin: "Ach, ja, dann programmiere in Swift doch mal eine Responder-Chain. Das sind in Objective-C nur ein paar Zeilen."
    *Langes, nachdenkliches Schweigen*
    Amin: "Ich glaube nicht, dass der Aufwand das Problem ist."

    Christian (der von Kienle) hat übrigens ziemlich Ahnung von Swift und es jedenfalls vor 2 Jahren nicht hinbekommen. Er hätte nämlich einen solchen Mechanismus für eine App benötigt.
    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 1 mal editiert, zuletzt von Amin Negm-Awad ()

  • Amin Negm-Awad schrieb:

    MCDan schrieb:

    Ups, habe ich bisher noch gar nicht verwendet.

    Ist ja auch nur für den Compiler interessant, oder wird diese Info auch zur Laufzeit verwendet/geprüft?
    Sie sind nur für den Swift-Compiler interessant.
    Und der kann mit den Optionals und Nicht-Optionals auf die Nase fallen. Da können dann beispielsweise Null-Pointer-Fehler bei nicht-optionalen Werten entstehen. Das erinnert dann doch an das gute, alte Java, das zwar keine Pointer hat (+lol+), aber einem trotzdem gerne eine NullPointerException vor den Kopf knallt. :D
    „Meine Komplikation hatte eine Komplikation.“
  • Das man das bisherige UI Konzept 1:1 übernehmen kann behaupte ich ja nicht. Wenn ich mir z.B. anschaue wie aufgeräumt iOS ist und wie "aufgebläht" und teilweise kompliziert macOS diesbezüglich ist, dann fände ich eine Grundrenovierung bei macOS schon mehr als angebracht. Dies kann ja auch nach und passieren, wie dies z.B. beim NSCollectionView bezüglich der NSCollectionViewDataSource passiert ist. Das alter Konzept funktioniert weiterhin und neue Apps verwenden einfach NSCollectionViewDataSource.

    Die Responder-Chain könnte man sicherlich auch ohne die Objective-C-RTE Funktionalität implementieren, wobei ich jetzt nicht behaupte, dass dies dann schön, geschweige denn elegant, aussieht! In diesem Fall erfolgt die komplette Dynamik nicht durch die Objective-C-RTE sondern per Programmcode. Wie gesagt, nicht schön aber es geht. Dies hebelt dann sicherlich die Sicherheit zur Compilierung bei Swift aus, von daher scheint eine Anpassung des UI Konzeptes sinnvoller.

    Update:

    Man könnte die neue Responder-Chain Logik natürlich auch mit ins UI Framework packen und mit einer Anpassung des Compilers würde sich diese sogar sehr elegant nutzen lassen.

    Ich kenne Swift allerdings nicht und evtl. würde mein aktueller Denkansatz mit Swift gar nicht funktionieren. Kann man in Swift Pointer auf Functions oder Closures verwenden oder wäre dies schon zu dynamisch für Swift? ?(

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von MCDan ()

  • Amin Negm-Awad schrieb:

    MCDan schrieb:

    Klar, erst denken dann schreiben. Da ich schon so lange in Objective-C programmiere, war es mir gar nicht direkt ersichtlich, dass es ein respondsToSelector: in anderen Sprachen wie z.B. Swift gar nicht gibt. :D

    In Swift müsste man dies dann z.B. mit einem Protocol lösen, bei dem die Methode einen Rückgabewert hat. Ist jetzt sicherlich nicht so schön wie in Objective-C, ginge aber auch.
    Nö, geht immer noch nicht. Dann weiß also die Responder-Chain, dass das Objekt auf die Nachricht hört. Und wie macht man jetzt ohne dynamische Bindung aus dem Text im Nib "myGreatCustomMethod:" ohne Objective-C-RTE einen Call? Und woher kennt überhaupt die Responder-Chain die Methode/Funktion, damit man sie ausführen kann? Was steht denn im Framework an der Stelle? if( [responder implements:…] ) { // un nu? }
    Dazu brauche ich mindestens die Fähigkeit, aus einem Text einen Selector zu machen und dann diesen – zur Laufzeit erst feststellbaren – Selector für einen dynamischen Dispatch zu nutzen. Ei, da ist wieder das dynamisch.

    Ich habe vielleicht zu wenig Ahnung von Swift, um einen Trick zu übersehen. Aber es geht ja eigentlich auch um das Grundkonzept, nicht eine überraschende Wendung. Wi dem auch sei, ich habe schon häufiger die Diskussion geführt:

    X: "Der Aufwand lohnt sich nicht für Apple."
    Amin: "Ach, ja, dann programmiere in Swift doch mal eine Responder-Chain. Das sind in Objective-C nur ein paar Zeilen."
    *Langes, nachdenkliches Schweigen*
    Amin: "Ich glaube nicht, dass der Aufwand das Problem ist."

    Christian (der von Kienle) hat übrigens ziemlich Ahnung von Swift und es jedenfalls vor 2 Jahren nicht hinbekommen. Er hätte nämlich einen solchen Mechanismus für eine App benötigt.
    Hättest Du dazu mal ein kleines Sample? Oder findet man das evtl. in Deinen Büchern?
  • MCDan schrieb:

    Kann man in Swift Pointer auf Functions oder Closures verwenden oder wäre dies schon zu dynamisch für Swift?
    Ziemlich leicht - und in Dictionaries kann man Closures auch packen.
    Die Funktionalität der responder chain kann man sehr einfach nachbauen - der einziger echte Nachteil, der mir dabei untergekommen ist:
    Man muss oft retain cycles brechen, die man mit Selektoren nicht hat.
  • MCDan schrieb:

    dass ein kleines Update einer App erst mal mehrere Tage benötigt, um das Projekt von einer Swift Version zur nächsten zu migrieren
    Ja, das war von Swift 1 nach 2 und von 2 nach 3 echt schlimm. Aber die Migration von Swift 3 auf 4 läuft eigentlich schmerzfrei. Es wird also besser. Meiner Meinung nach ist Swift3, die erste Version, die man auch produktiv einsetzen kann.
  • MCDan schrieb:

    Das man das bisherige UI Konzept 1:1 übernehmen kann behaupte ich ja nicht. Wenn ich mir z.B. anschaue wie aufgeräumt iOS ist und wie "aufgebläht" und teilweise kompliziert macOS diesbezüglich ist, dann fände ich eine Grundrenovierung bei macOS schon mehr als angebracht. Dies kann ja auch nach und passieren, wie dies z.B. beim NSCollectionView bezüglich der NSCollectionViewDataSource passiert ist. Das alter Konzept funktioniert weiterhin und neue Apps verwenden einfach NSCollectionViewDataSource.

    Die Responder-Chain könnte man sicherlich auch ohne die Objective-C-RTE Funktionalität implementieren, wobei ich jetzt nicht behaupte, dass dies dann schön, geschweige denn elegant, aussieht! In diesem Fall erfolgt die komplette Dynamik nicht durch die Objective-C-RTE sondern per Programmcode. Wie gesagt, nicht schön aber es geht. Dies hebelt dann sicherlich die Sicherheit zur Compilierung bei Swift aus, von daher scheint eine Anpassung des UI Konzeptes sinnvoller.

    Update:

    Man könnte die neue Responder-Chain Logik natürlich auch mit ins UI Framework packen und mit einer Anpassung des Compilers würde sich diese sogar sehr elegant nutzen lassen.

    Ich kenne Swift allerdings nicht und evtl. würde mein aktueller Denkansatz mit Swift gar nicht funktionieren. Kann man in Swift Pointer auf Functions oder Closures verwenden oder wäre dies schon zu dynamisch für Swift? ?(
    Das glaube ich nicht, Tim. Es bleibt dabei, dass die Zuordnung von UI-Element zu Code erst zur Laufzeit erfolgt und sowohl Bezeichner im UI-Element als auch Code erst erstellt werden, nachdem das Framework (also hier AppKit) compiliert ist. Das wird schwierig ohne RTE.

    Was natürlich geht, ist es die RTE zu "faken" und einfach zu jedem potentiellen Responder ein Dictionary anzulegen. Die Actions sind dann Blöcke. So machen wir das bei Objective-Cloud für Webservices. Ich habe hier gerade einen Dienst, der vielleicht über 15 Seiten verfügt, bei dem dann zu jedem URL-Muster ein Block existiert. Bereits bei dieser geringen Anzahl ist das die Hölle, weil natürlich die Bezeichner fehlen, alles in einer "Link-Service"-Methode steht usw.

    Eine App mit ein paar Dutzend Actionmethoden … Gute Nacht.

    PS: Ja, iOS ist aufgeräumter, sicherlich auch weil es moderner ist. Aber es ist auch modaler. Im Prinzip befindest du dich immer an einem Zustand, modelliert durch den View-Controller. Das ist was anderes als ein Infopanel, welches sich theoretisch auf ganz viele und vor allem ganz unterschiedliche Dinge beziehen kann. Oder eben auch eine Actionmethode, die sich mal auf eine Selektion in einem Textfeld, mal auf ein Fenster beziehen kann. So etwas passiert dir einfach bei iOS selten bis nie.

    t-no schrieb:

    MCDan schrieb:

    Kann man in Swift Pointer auf Functions oder Closures verwenden oder wäre dies schon zu dynamisch für Swift?
    Ziemlich leicht - und in Dictionaries kann man Closures auch packen.Die Funktionalität der responder chain kann man sehr einfach nachbauen - der einziger echte Nachteil, der mir dabei untergekommen ist:
    Man muss oft retain cycles brechen, die man mit Selektoren nicht hat.
    Ja, mach mal.
    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 ()

  • WernerB schrieb:

    Amin Negm-Awad schrieb:

    MCDan schrieb:

    Klar, erst denken dann schreiben. Da ich schon so lange in Objective-C programmiere, war es mir gar nicht direkt ersichtlich, dass es ein respondsToSelector: in anderen Sprachen wie z.B. Swift gar nicht gibt. :D

    In Swift müsste man dies dann z.B. mit einem Protocol lösen, bei dem die Methode einen Rückgabewert hat. Ist jetzt sicherlich nicht so schön wie in Objective-C, ginge aber auch.
    Nö, geht immer noch nicht. Dann weiß also die Responder-Chain, dass das Objekt auf die Nachricht hört. Und wie macht man jetzt ohne dynamische Bindung aus dem Text im Nib "myGreatCustomMethod:" ohne Objective-C-RTE einen Call? Und woher kennt überhaupt die Responder-Chain die Methode/Funktion, damit man sie ausführen kann? Was steht denn im Framework an der Stelle? if( [responder implements:…] ) { // un nu? }Dazu brauche ich mindestens die Fähigkeit, aus einem Text einen Selector zu machen und dann diesen – zur Laufzeit erst feststellbaren – Selector für einen dynamischen Dispatch zu nutzen. Ei, da ist wieder das dynamisch.

    Ich habe vielleicht zu wenig Ahnung von Swift, um einen Trick zu übersehen. Aber es geht ja eigentlich auch um das Grundkonzept, nicht eine überraschende Wendung. Wi dem auch sei, ich habe schon häufiger die Diskussion geführt:

    X: "Der Aufwand lohnt sich nicht für Apple."
    Amin: "Ach, ja, dann programmiere in Swift doch mal eine Responder-Chain. Das sind in Objective-C nur ein paar Zeilen."
    *Langes, nachdenkliches Schweigen*
    Amin: "Ich glaube nicht, dass der Aufwand das Problem ist."

    Christian (der von Kienle) hat übrigens ziemlich Ahnung von Swift und es jedenfalls vor 2 Jahren nicht hinbekommen. Er hätte nämlich einen solchen Mechanismus für eine App benötigt.
    Hättest Du dazu mal ein kleines Sample? Oder findet man das evtl. in Deinen Büchern?
    Wozu jetzt genau ein Sample? Die Funktionsweise er Responder-Chain ist freilich beschrieben.
    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:

    Das glaube ich nicht, Tim. Es bleibt dabei, dass die Zuordnung von UI-Element zu Code erst zur Laufzeit erfolgt und sowohl Bezeichner im UI-Element als auch Code erst erstellt werden, nachdem das Framework (also hier AppKit) compiliert ist. Das wird schwierig ohne RTE.
    Was natürlich geht, ist es die RTE zu "faken" und einfach zu jedem potentiellen Responder ein Dictionary anzulegen. Die Actions sind dann Blöcke. So machen wir das bei Objective-Cloud für Webservices. Ich habe hier gerade einen Dienst, der vielleicht über 15 Seiten verfügt, bei dem dann zu jedem URL-Muster ein Block existiert. Bereits bei dieser geringen Anzahl ist das die Hölle, weil natürlich die Bezeichner fehlen, alles in einer "Link-Service"-Methode steht usw.

    Eine App mit ein paar Dutzend Actionmethoden … Gute Nacht.
    Hm, man implementiert ja nur, genau wie jetzt in Objective-C, die Methoden (Actions) welche im UI verwendet werden. Dies wäre mit Swift ja nicht anders. Evtl. denke ich auch zu einfach und sehe die Spezialfälle nicht.

    Ich habe z.B. einen Menu Item mit der Action showHelloWorld: mit dem Target First Responder. In diesem Fall wird ja die Responder Chain herangezogen, um zur Laufzeit das passende Target für den Aufruf der Methode zu ermitteln. In Objective-C implementiere ich dann einfach die Methode showHelloWorld: in einer Klasse, bei der sich zur Laufzeit ein Objekt der Klasse in der Responder Chain befindet. Seit macOS 10.10 (mit kleinen Bugs) z.B. in einem ViewController, welcher als contentViewController in einem WindowController verwendet wird.

    AppKit sorgt jetzt dafür, dass zur Laufzeit das passende Target aus der Responder Chain ermittelt wird, welches auf die besagte Action showHelloWorld: reagiert. Die genaue Implementierung unter Objective-C kenne ich nicht, aber darin wird sicherlich die Methode respondsToSelector: verwendet, um zu prüfen, ob ein Objekt auf die gesuchte Action, also den Selector reagiert. Klar, macht unter Objective-C natürlich Sinn einfach die Objekte zu fragen ob diese die Methode xyz kennen. Bei einem Treffer ist dann das passende Target gefunden.

    In einer anderen Sprache z.B. unter Swift hindert mich aber nichts daran z.B. eine Function oder ein Closure unter einem Namen bzw. einem Selector für ein Objekt zu registrieren. Über ein Schlüsselwort wie z.B. IBAction könnte der Compiler sogar den entsprechenden Code für diese Registrierung automatisch erzeugen und direkt compilieren. Dies kostet mich dann keine weitere Zeile Code ausser halt die Verwendung des Schlüsselwortes. Die Implementierung zur Ermittlung des passenden Targets fragt dann einfach alle Objekt in der Responder Chain, ob diese z.B. etwas mit der gesuchten Methode bzw. dem Selector anfangen können. Die Methode könnte z.B. auch respondsToSelector: heißen. Wenn für das Objekt also ein entsprechender Namen bzw. Selector registriert ist, dann würde es als Target in Frage kommen. Über eine Methode die z.B. auch performSelector:withObject: heißen könnte, lässt sich die Methode in dem Target (Objekt) dann einfach aufrufen.

    So wird es ja sicherlich auch unter Objective-C funktionieren, wobei hier die Ermittlung des Targets und der Aufruf der Action dynamisch über die RTE erfolgt.

    In Swift lassen sich Functions oder Closures ja anscheinend auch über einen Pointer darauf aufrufen, wenn ich den Post von t-no (siehe oben) richtig verstanden habe. Hier wäre halt ein wenig "Overhead" erforderlich, welcher jedoch komplett vom AppKit Framework und ggf. automatisch vom Compiler durch Schlüsselwörter abgedeckt werden könnte.

    Damit sollten dann 99,9% aller benötigten Fälle abgedeckt sein, wenn ich jetzt nicht etwas total übersehen habe.
  • MCDan schrieb:

    In einer anderen Sprache z.B. unter Swift hindert mich aber nichts daran z.B. eine Function oder ein Closure unter einem Namen bzw. einem Selector für ein Objekt zu registrieren.
    Um di Komplexität der RC geht es in der Tat nicht. Es geht ja um das Grundproblem.

    Einen Selector kannst du eben gerade nicht registrieren. Weil das Matching von Selector zum Code (also der Methode) ja gerade wider dynamisches Dispatching wäre, welches bei einer früh bindenden Sprache nicht möglich ist. Deshalb brauchst ja gerade die späte Bindung.

    Ein Closure in ein Dictionary zu packen geht, ist aber kein Ersatz, wie ich oben schon schrieb. Das hat ganz einfache Gründe:

    - Der Closure ist ein Wert, kein Code. Wie findest du den in den Sourcen? Der taucht nicht einmal im Pop-Down für Methoden auf.
    - Dementsprechend kannst du auch nicht drauf verlinken. Es gibt keine Möglichkeit etwa im IB zu klicken, um zur Methode zu kommen.
    - Wie leitet man eigentlich Blöcke von einer Basisklasse zu Subklassen ab? Die gehören ja nicht zu einer Klasse. Wie mache ich es denn, wenn ein Window-Controller bereits -close hat und ich das in meiner Subklasse nur kurz verändern möchte und dann die Basisimplementierung aufrufe?

    Was man im Prinzip macht, ist das, was man auch in Java macht: Konfigurationsfiles schreiben, die mappen. Das mag auf den ersten Blick "banal" klingen, ist aber wirklich ein Hindernis. Frag mal die Java-Leut … Ich habe das gerade aktuell in einem Projekt, weil Objective-Cloud URL auf Blöcke mappt, also etwa /resources/:resourceID auf -showResourceDetailsWithRequest:. (Es gibt inzwischen einen Ansatz, das unmittelbar auf Methoden zu mappen, der ist aber noch nicht ausgereift und neuer als das Projekt.) Das ist genau diese Lösung, wobei natürlich statt Selektoren URL-Pattern dem Matching unterliegen. Fast 1:1 gleich.

    Auch ohne GUI verbringe ich einen Gutteil der Arbeit damit, über die ewige Suche zu fluchen. Weder das Pattern der URL noch der Block sind für Xcode irgendetwas, was indiziert wird.

    Wenn wir uns mal sehen, zeige ich dir das in der Praxis. Du wirst sehen, was das Problem ist. Wann bist du mal wieder in Köln oder Umgebung? Ich zeig dir dann Projekt und Code.

    MCDan schrieb:

    Über ein Schlüsselwort wie z.B. IBAction könnte der Compiler sogar den entsprechenden Code für diese Registrierung automatisch erzeugen und direkt compilieren.
    Richtig, das könnte er. Er könnte ein RTE mit später Bindung aufbauen. Das wäre dann Objective-C.

    Swift will aber früh binden.

    Es ist ja egal, ob das RTE bereits gelinkt wird oder der Compiler es jedesmal neu baut. Das ist zwar blöder, wäre aber in der Tat möglich. Mit einem spät bindenden Swift. Das gibt es nur nicht. Und das ist ja vom Konzept her gerade nicht gewollt.

    Und ja, natürlich, ist es möglich in Swift einen Objective-C-Interpreter zu schreiben, der dann alles kann, was Objective-C kann. Du kannst ja nicht die Diskussion über eine Sprache damit führen, dass die Sprache anders sein könnte. Und ich kann mir dann die ganze Arbeit machen, einen dynamsichen Aufruf selbst zu programmieren und ich kann mir dann auch die Arbeit machen, so etwas wie in dem Selector-Closure-Mapping so etwas wir Ableitung und Überschreiben zu implementieren. Ich kann also einfach die RTE nachprogrammieren. Am Ende ist ohnehin alles Assembler und die RTE ist ja auch in C geschrieben. Ich kann mir also ein neues Swift denken, dass das alles kann.

    Aber das ist ja gerade nicht der Sinn von Swift. Es *soll* ja nicht dynamisch sein, weil man sich damit angeblich Vorteile erkauft. Deshalb ist ja die Argumentation "Ich will keine späte Bindung und brauche deshalb kein RTE und außerdem baue ich mir späte Bindung und schreibe mir selbst ein RTE" ja sinnbefreit. Wenn ich das gerade möchte, dann soll es in der Sprache sein. Dazu gibt es ja Hochsprachen.

    Man kann in Assembler übrigens auch OOP programmieren. Man kann sich in Assembler Klassen bauen, man kann Klassen in Assembler instantieren. Man kann in Assembler Stackframes für Calls bauen, man kann einen Instanzzeiger automatisch übergeben. Auch in Assembler.

    Also brauche ich doch Hochsprachen gar nicht, nicht wahr? In Assembler kann ich das ja alles haben, da gibt es keinen Unterschied von Assembler zu Swift und Objective-C. Damit sind in Assembler 99 % der Fälle abgedeckt. (Wenn man mal so unwichtige Dinge weglässt, dass Methoden anders als Blöcke Teil eines Typs sind. Dabei hat es Swift doch so sehr mit Typen.) Es ist aber nicht belanglos, ob etwas Sprachbestandteil ist oder nachprogrammiert. Genau aus diesem Grunde gibt es Hochsprachen: Weil es einen Unterschied macht, was in der Sprache enthalten 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"?

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

  • WernerB schrieb:

    Amin Negm-Awad schrieb:

    Na, ja, es ging ja jetzt darum, was Apple derzeit noch macht. Und das ist dann ja häufig neu.
    ...
    Ja, aber auch jetzt noch weitestgehend in C implementiert, Metal2 oder GCD z.B.. Und dann in entsprechende Objective-C-Wrapper gepackt. Ähnlich wird es auch mit Klassen wie NS(Mutable-)String aussehen.
    Ich meinte jetzt zwar mehr die Applikationsentwicklung, also das, was sie nehmen, wenn sie die Wahl zwischen Swift und Objective-C haben. Und da nehmen sie dann doch lieber Objective-C. Von wegen "eat your own dog food". Aber sei's drum:

    Selbstverständlich sind Systemerweiterungen in C geschrieben.

    NSString ist aber schon nicht mehr ein verkappter C-String. Das erkennst du leicht daran, dass \0 in NSString enthalten sein darf, also nicht terminatorbasiert, sondern längenbasiert ist. Aber ja, irgendwo werden UTF16-Zeichen abgelegt.
    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 1 mal editiert, zuletzt von Amin Negm-Awad ()

  • MCDan schrieb:

    t-no schrieb:

    Apple "verbessert" Objective-C nur noch, um das Zusammenspiel mit Swift zu vereinfachen, etablierte Apps sind auf breiter Front dabei, zu migrieren, und neue Objective-C Projekte haben Seltenheitswert (ausser vielleicht intern bei Apple ;-).
    Ich werden meinen Kunden auch weiterhin Objective-C für neue Projekte empfehlen. Wie soll man einem Kunden auch verkaufen, dass ein kleines Update einer App erst mal mehrere Tage benötigt, um das Projekt von einer Swift Version zur nächsten zu migrieren, damit man danach dann die gewünschte Änderung durchführen kann. Ich kenne keinen Kunden der so etwas bezahlt.

    Evtl. Änderungen für eine neue iOS Version sind schon schwierig zu verkaufen. Wenn dann auch noch Aufwand für jede neue Swift Version entsteht, ist der Kunde natürlich schnell mehr als sauer.
    Die ist für mich auch ein wichtiger Punkt, wenn es um das Thema "Zukunftsfähigkeit" geht. Eine Plattform, oder eine Sprache, sollte einen gewissen Long Term Support bieten und ich bin mir nicht sicher, ob man sich hier immer alleine auf die Migration-Tools verlassen kann. Es ist auch unschön, wenn man dauernd in Migrationsszenarien gedrängt wird, weil vielleicht mit einer neuen Sprachversion, alte Programme auf einmal überhaupt nicht mehr laufen.
  • WernerB schrieb:

    Amin Negm-Awad schrieb:

    Und natürlich ist bei Apple intern fast alles Objective-C. Die wissen schließlich was Swift und Obejctive-C sind und können. Wieso sollten sie also Swift nehmen? Das ergäbe doch gar keinen Sinn.
    Apple wäre doch auch mit dem Klammerbeutel gepudert, eine Code-Basis umzuschreiben, die in Teilen 30 Lenze auf dem Buckel hat und somit ausgereift ist. Und (massive) Geschwindigkeitsvorteile von Swift scheinen auch nicht zu existieren.
    Das ist ein interessanter Punkt, vielleicht sollte man mal einen Benchmark laufen lassen. Aber ich denke, bei allen "neuen" Sprachen geht es in erster Linie um Übersichtlichkeit, vielleicht bessere Wartbarkeit.