Swift

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

  • Amin Negm-Awad schrieb:

    Ich stell mich nicht an. Ich würde gerne wissen was an << und >> für raus bzw. rein logischer sein soll als an << und >> für rein bzw. raus.

    Ich glaube , dass dem eine ganz private Logik zugrunde liegt.


    Nein, das ist eigentlich ziemlich einfach zu verstehen und auch sehr elegant umgesetzt.

    Wenn man in C++ (wie auch in Swift) einen Infix-Operator wie << überlädt, tut man das für den linken Operanden. Eine Stream-Expression fängt in C++ also immer links mit dem Stream-Objekt an. Und der Operand arbeitet nicht nur auf einer ostream-Referenz, sondern er gibt sie auch wieder als Rückgabewert zurück, so daß man ihn konkatenieren kann, so oft man will.

    Daß man etwas auf der Konsole ausgeben will ist nur der "zufällige" Sonderfall, daß das Stream-Objekt die vordefinierte ostream-Instanz cout ist und keine Datei, kein temporärer Puffer im RAM oder sonst irgendein Objekt, dessen Klasse von ostream abgeleitet ist.

    Ganz konkret sieht eine Ausgabe in C++ also z.B. so aus:

    Quellcode

    1. cout << "x = " << x;


    Der Operator zeigt also völlig logisch, daß die rechten Operanden in genau der offensichtlichen Reihenfolge in den Stream reingeschoben werden.

    Eine formatierte Ausgabe geht auch ganz einfach, nämlich so:

    Quellcode

    1. cout << "x = " << left << setw(5) << x;


    Man schmeißt einfach die Formatierungssteuerungs-Objekte mit in den Ausgabestrom und alles funktioniert automatisch richtig.

    Und der Witz an der Sache ist, daß das mit allen Objekten aller ostream-abgeleiteten Klassen exakt genauso funktioniert – die Konsolen-Ausgabe ist nur ein Spezialfall, der eben keinen Extra-Befehl braucht ("print" – aber Moment mal, wo ist da eigentlich das Papier?), sondern man gibt einfach bloß in das ostream-Objekt aus, an dem zufällig die Konsole hängt.

    Und analog funktioniert es für die istream-Klasse, nämlich so:

    Quellcode

    1. source >> line;


    Auch hier zeigt der Pfeil wieder ganz offensichtlich, daß aus dem istream source Daten in die Variable line herausgezogen werden.

    Völlig offensichtlich und intuitiv.

    Und da C++ mehrfache Vererbung unterstützt, gibt es auch auf diesem Weg die Klasse iostream, deren Objekte gleichzeitig beides können (z.B. für I/O-Ports). (Das würde man in Objective-C und Swift auf anderem Weg lösen müssen.)

    Solche Konstrukte sind in C++ sehr einfach, übersichtlich und elegant nutzbar, und Swift führt diese sprachliche Eleganz auf Compiler-Ebene jetzt eben mit der dynamischen Eleganz der Objective-C-Runtime zusammen in eine gemeinsame, konsistente Sprache.

    In C++ war die Operator-Überladung übrigens gegenüber Swift noch relativ eingeschränkt: Es gab immer nur die vordefinierten Operatoren und innerhalb von Expressions war die Auswertungs-Priorität fest vorgegeben; Es galt also z.B. immer die Punkt-vor-Strich-Semantik, auch bei Überladung.

    In Swift kann man nicht nur aus den für Operatoren zugelassenen Zeichen beliebige Operatoren definieren, sondern auch deren Auswertungs-Priorität beliebig festlegen.

    Wie schon jemand zuvor gesagt hatte, habe auch ich noch nie ein Problem mit der Operator-Überladung erlebt (wobei ich die selber schon mehrfach genutzt habe), aber es ist natürlich ein sehr expressives Werkzeug, das erhöhte Ansprüche an die Konzeption und vor allem auch Dokumentation stellt.

    Normale, benannte Funktionen und Methoden erklären sich aber eben auch nicht generell von selbst, gerade was ihre Semantik angeht.
  • RegExpressive schrieb:

    Quellcode

    1. cout << "x = " << x;


    Der Operator zeigt also völlig logisch, daß die rechten Operanden in genau der offensichtlichen Reihenfolge in den Stream reingeschoben werden.


    Quellcode

    1. x>>y>>cout

    Der Operator zeigt also völlig logisch, daß die linken Operanden in genau der offensichtlichen Reihenfolge in den Stream reingeschoben werden.

    Das ist völlig beliebig.

    Dass der Infix-Operator links überladen wird, ist eine Regel, die genauso umgekehrt gelten könnte. Sie hat aber auch nichts mit der Intuition und Logik der obigen Anweisung zu tun, sondern ist eine innere Sprachregel, die sich daher nicht intuitiv erschließt.
    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:

    RegExpressive schrieb:

    Quellcode

    1. cout << "x = " << x;


    Der Operator zeigt also völlig logisch, daß die rechten Operanden in genau der offensichtlichen Reihenfolge in den Stream reingeschoben werden.


    Quellcode

    1. x>>y>>cout

    Der Operator zeigt also völlig logisch, daß die linken Operanden in genau der offensichtlichen Reihenfolge in den Stream reingeschoben werden.

    Das ist völlig beliebig.

    Dass der Infix-Operator links überladen wird, ist eine Regel, die genauso umgekehrt gelten könnte. Sie hat aber auch nichts mit der Intuition und Logik der obigen Anweisung zu tun, sondern ist eine innere Sprachregel, die sich daher nicht intuitiv erschließt.


    Nein, daran ist nichts beliebig.

    Erstens zeigen die Pfeile eindeutig die Richtung des Datenflusses an. Das ist kein bißchen beliebig, sondern ist für jeden noch so unbedarften Programmierer eindeutig und offensichtlich.

    Bleibt also nur noch die Frage, ob das Stream-Objekt links oder rechts steht.

    Operatoren sind aber letztlich auch nur ganz normale Methoden, lediglich in modifizierter Schreibweise, und es ist völlig logisch und offensichtlich (und ist deshalb auch sowohl in C++ als auch in Swift so implementiert), daß beim Aufruf von Operatoren dieselbe Anordnung gilt wie bei allen anderen Methoden auch: Das Objekt kommt immer zuerst, dann der Methoden-Identifier und dann der oder die Parameter.

    Quellcode

    1. cout << "x = " << x;


    ist in C++ nur eine übersichtlichere Schreibweise für:

    Quellcode

    1. cout.operator<<("x = ").operator<<(x);


    Das Objekt in einer Ausgabe-Kette ist logischerweise der Stream, also kommt das logischerweise auch zuerst und steht damit links, so wie bei jedem anderen Methoden-Aufruf auch.

    Das ist die einzige plausible Realisierung dieses Patterns in einer C-verwandten Sprache. Anders kann es gar nicht (konsistent) sein, und das ist auch sehr intuitiv zu verstehen, weil es sich konsistent aus dem Grundprinzip der Sprache ergibt.

    Oder kennst Du irgendeinen Fall in einer der C-verwandten Sprachen, in dem das Objekt rechts von der Methode und sogar den Parametern käme? Mir fällt keiner ein.

    Dasselbe Pattern müßte selbst in Objective-C formuliert sinngemäß so aussehen:

    Quellcode

    1. [[cout OutWithCString: "x = "] OutWithDouble: x]


    Selbst da wäre die Reihenfolge noch dieselbe, aber da sieht man schon sehr klar den Vorteil der Operator-Überladung, umso mehr, je länger der Ausdruck wird.

    Weil das in Objective-C effektiv ein Krampf wäre, greift man dort dann ja wohl auf das alte printf zurück; Wenn man schon mal mit cout << gearbeitet hat, ist printf im Vergleich aber wirklich nur noch schmerzhaft und primitiv (ganz zu schweigen von fehleranfällig, gerade bei Änderungen).

    Diese Art von Pattern (cout << ist ja nur das bekannteste Beispiel) wird jetzt mit Swift auch direkt verfügbar, aber gleichzeitig gehen eben auch die schicken Pattern, die auf der Objective-C-Runtime basieren. Das ist kein Widerspruch und kann sich gegenseitig auch gar nicht ersetzen, aber beide können sich genial ergänzen. Und das ist offenbar gerade der Witz an Swift, denn C++ und Objective-C können jeweils nur das eine oder das andere – nur Swift kann beides nativ und ohne Sprach-Brüche oder Zusatzkomplikationen.
  • Es geht nicht darum, ob die das anzeigen, sondern wie herum. Und x >> cout zeigt es genau so an wie cout << x. Daher beliebig.

    Alles andere ist Ausführung dazu, warum es in C++ so ins Konzept passt. Übrigens ist es nicht logischerweise das erste, sondern definitionsmäßig. Es könnte genau so das letzte sein. Das hat nichts mit Intuition zu tun. Und es ist ebenfalls beliebig, da C++ nicht so sein muss, wie es ist, sondern so gemacht worden ist.

    Zu Swift und Objective-C: Da ergänzt sich ganz wenig, da Swift die späte Bindung eigentlich gar nicht will. Nicht umsonst musste für Core Data ein eigenes Schlüsselwort eingeführt werden, damit es überhaupt möglich ist. Das zeigt wenig von Ergänzung, mehr von Amputation. Dumm ist es nur, wenn man eine ähnliche Technologie selbst programmieren möchte. Das geht nämlich dann gar nicht in Swift.
    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:

    Es geht nicht darum, ob die das anzeigen, sondern wie herum. Und x >> cout zeigt es genau so an wie cout << x. Daher beliebig.


    Nein, nicht mal ansatzweise. Das Objekt, für dessen Klasse die Methode (hier die Operator-Methode) aufgerufen wird, ist immer links. Deshalb ist es schon von daher offensichtlich, eindeutig und zwingend, daß der Stream am Anfang steht.

    Es gibt eine ganze Reihe von klaren Gründen, warum es eindeutig, zwingend und offensichtlich cout << "x = " << x ist.

    Amin Negm-Awad schrieb:

    Alles andere ist Ausführung dazu, warum es in C++ so ins Konzept passt. Übrigens ist es nicht logischerweise das erste, sondern definitionsmäßig. Es könnte genau so das letzte sein. Das hat nichts mit Intuition zu tun. Und es ist ebenfalls beliebig, da C++ nicht so sein muss, wie es ist, sondern so gemacht worden ist.


    Intuition schwebt absolut niemals im leeren Raum, sondern basiert immer auf einem aus dem Kontext bezogenen oder manchmal auch angeborenen Hintergrund. Wenn man die Sprache wenigstens ansatzweise verstanden hat, was ohnehin zwingend ist, wenn man sie überhaupt benutzen will, ergibt sich schon daraus zwingend, wie das Pattern funktioniert und daß es nur exakt so herum sein kann wie beschrieben.

    (Hier C++, aber obwohl Swift es nicht für genau diesen Zweck nutzt, müßte das Pattern dort wie gesagt auch dort genauso funktionieren und auch aus denselben Gründen, obwohl es eine andere Sprache ist.)

    Amin Negm-Awad schrieb:

    Zu Swift und Objective-C: Da ergänzt sich ganz wenig, da Swift die späte Bindung eigentlich gar nicht will.


    Sagt wer?

    Amin Negm-Awad schrieb:

    Nicht umsonst musste für Core Data ein eigenes Schlüsselwort eingeführt werden, damit es überhaupt möglich ist. Das zeigt wenig von Ergänzung, mehr von Amputation.


    Das sieht aus meiner Perspektive ganz anders aus.

    Symbolisch-dynamischer Lookup ist teuer – und wenn er wirklich durchgeführt werden muß und schon nicht gecached ist, sogar sehr teuer!

    Selbst wenn er gecached ist, ist er immer noch teurer als der langsamste virtuelle Aufruf einer statisch gebundenen Methode.

    Daß selbst in völlig statisch konstruierten Objektgefügen in Objective-C zwingend ausschließlich diese teuren Methoden-Aufrufe (=Messages) benutzt werden müssen (weil es schlicht nichts anderes gibt) ist ein Performance-Problem, das unter anderem zur Ausgliederung performancekritischer Algorithmen in C++ zwingt. Es ist aber auf die Dauer Murks, zwei völlig verschiedene Sprachen mit komplett entgegengesetzten Objekt- und Klassen-Konzepten und völlig unterschiedlicher Syntax bloß deshalb zwangsverheiraten zu müssen.

    Swift erlaubt dem Compiler grundsätzlich, Klassen und Objekte weitgehend so effizient zu implementieren wie das bei C++ geht (also bis hin zu komplett kostenlosen Klassen, die exakt Null Performance-Overhead mit sich bringen!). Wobei der Optimizer in der aktuellen Beta sicherlich noch rudimentär ist, weil der natürlich noch eine Menge Verfeinerungen braucht.

    Soweit ich das bisher mitbekommen habe, sieht es mir eher danach aus, daß man in Swift schlicht extra sagen muß, wenn man wirklich aus guten Gründen an einer bestimmten Stelle den zwar zur Laufzeit flexiblen, aber dafür auch teuren und vom Compiler effektiv nicht optimierbaren Mechanismus haben will.

    Es wäre idiotisch, wenn Apple sich selbst und den Entwicklern für ihre Plattformen die Möglichkeiten der dynamischen Runtime aus der Hand schlagen wollte, nicht zuletzt deshalb, weil es dann Blödsinn gewesen wäre, Swift überhaupt erst zu entwickeln. Dann hätte C++ nämlich eh schon gereicht.

    Ganz im Gegenteil bin ich sogar sehr sicher, daß Swift sogar ein sehr deutliches Zeichen dafür ist, daß die Dynamik, auf der Cocoa zu wesentlichen Teilen basiert, gerade weiterentwickelt werden soll. Nur soll der Code, der diese Dynamik tatsächlich gar nicht braucht, vom Compiler besser optimierbar werden. Und dafür kann es ggf. notwendig werden, daß man als Programmierer sagen muß, wo man sie denn wirklich haben will, und auf dem Rest kann sich der Optimizer austoben (wenn er denn mal fertig ist).

    Amin Negm-Awad schrieb:

    Dumm ist es nur, wenn man eine ähnliche Technologie selbst programmieren möchte. Das geht nämlich dann gar nicht in Swift.


    Was für eine "Technologie" meinst Du, und was bringt Dich auf Deine Schlußfolgerung?
  • A.

    So schwer ist das eigentlich nicht. Die äußere Lesbarkeit einer Sprache lässt sich kaum aus einer inneren Notwendigkeit herleiten. In deinem "logischen" Schluss ist alles intuitiv, wenn es einer inneren Logik folgt. Es geht aber gerade darum, ob diese innere Logik so sein muss. Bei dir wäre Brainfuck leicht lesbar, weil es der Logik von Brainfuck folgt.

    Ich finde es ja toll, dass du offensichtlich so in C++ denkst, dass du gar nicht mehr anders denken kannst.

    B.
    Du hättest vielleicht einfach komplett zitieren sollen. Dann hättest du in deinem Beitrag bereits die Antworten auf deine Fragen stehen.

    Der nächste Punkt, der mit Swift wohl gar nicht geht: Proxys. Auch so ein dynamisches Ding.
    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"?
  • Message-Forwarding

    Aber ist nur eine erste Einschätzung. Sicherlich kann man noch keine genauen Aussagen machen, da wir alle die Sprache ja nur wenig kennen. (Und deutlich weniger als Objective-C.)
    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:

    A.

    So schwer ist das eigentlich nicht. Die äußere Lesbarkeit einer Sprache lässt sich kaum aus einer inneren Notwendigkeit herleiten. In deinem "logischen" Schluss ist alles intuitiv, wenn es einer inneren Logik folgt. Es geht aber gerade darum, ob diese innere Logik so sein muss. Bei dir wäre Brainfuck leicht lesbar, weil es der Logik von Brainfuck folgt.

    Ich finde es ja toll, dass du offensichtlich so in C++ denkst, dass du gar nicht mehr anders denken kannst.


    Na, jetzt komm' mal runter von Deiner Palme! ;)

    Ich habe gerade aufgezeigt, daß mir sehr wohl klar ist, was die spezifischen Eigenheiten der verschiedenen Sprachen sind. Und die sind ja gerade auch der Witz im Zusammenhang mit Swift.

    Du behauptest hier mit großen Verrenkungen eine Mehrdeutigkeit, die schon aus der gemeinsamen Grundsprache C heraus schlicht nicht existieren kann. Das Grundprinzip, daß in Leserichtung zuerst links das Objekt kommt, dann der Operator / Methodenname und danach rechts der oder die Parameter, ist in C und jeder damit verwandten Syntax (also neben C++ und Objective-C und Swift u.a. auch noch Java, C#, PHP usw.) einfach zwingend und ohne jede Zweideutigkeit.

    Und daß ein Pfeil << bzw. >> schlicht die Richtung anzeigt, in der die Daten fließen, könnte offensichtlicher nicht sein.

    Da ist einfach nichts mehrdeutig.

    Das Problem mit dem Status Quo Ante war ja aber eben gerade, daß man bei komplexerem und dabei performancekritischem Code unter OS X (beide Varianten) effektiv gezwungen war, mit zwei komplett verschiedenen Syntaxen zu jonglieren und die miteinander zu mischen, weil die Performance von sauber abstrahierten C++-Code erheblich höher sein kann als die gleichermaßen abstrahierten Objective-C-Codes. Nur ist diese Mischung eben konzeptionell eklig und syntaktisch unschön.

    Diese Notwendigkeit kann mit Swift zumindest potentiell komplett wegfallen, weil es mit entsprechend optimiertem Compiler sowohl so schnell und wendig wie C++ sein kann als auch so dynamisch und auf höherem Level elegant wie Objective-C, wo das tatsächlich gebraucht wird. Und das eben mit einer einzigen gemeinsamen Syntax.

    Apple hätte diese Vereinigung natürlich auch unter einer Objective-C-Syntax versuchen können, aber ich bin wahrscheinlich auch nicht der einzige, der erleichtert ist, daß sie sich syntaktisch eher an C++ und ähnlichen Sprachen orientiert haben. Das ist aber letztlich nur eine äußerliche Präferenz – die Fähigkeiten der Sprache sind davon so oder so unberührt.

    Und das ändert eben auch nichts daran, daß Swift nach wie vor auch die Fähigkeiten von Objective-C weitestgehend unterstützt, sie aber eben mit den Fähigkeiten von C++ (und noch einigem mehr) zusammenbindet.

    Amin Negm-Awad schrieb:

    B.
    Du hättest vielleicht einfach komplett zitieren sollen. Dann hättest du in deinem Beitrag bereits die Antworten auf deine Fragen stehen.


    Schau' einfach selber nach: Ich habe Deinen Post in der Tat komplett zitiert! Und nein, Du hast nirgends plausibel erklärt, wie die behauptete Mehrdeutigkeit in irgendeiner C-verwandten Sprache funktionieren könnte.

    Amin Negm-Awad schrieb:

    Der nächste Punkt, der mit Swift wohl gar nicht geht: Proxys. Auch so ein dynamisches Ding.


    Für die generische, nicht vom Compiler kontrollierbare Behandlung von Runtime-Messages habe ich in der Tat in Swift noch nichts gesehen; Dieser Spezialfall wird möglicherweise zumindest bis auf weiteres noch Objective-C brauchen, wenn sie da nicht noch einen entsprechenden Mechanismus einführen.
  • Na, du bist ja eher drauf, wie die Länge deiner Beiträge zeigt.Mehrdeutig ist nicht ">> bedeutet von links nach rechts" und "<< bedeutet von rechts nach links". Aber welches bedeutet "herein" und welches "heraus"? Aber ich weiß auch nicht, wie ich es noch erklären soll. Ausdruckstanz?

    Es geht nicht um implizite Bedeutungen. Selbstverständlich ist das innerhalb der Sprache konsistent. "print" et al. versteht indessen jeder. Ganz ohne das Sprachkonzept. Das ist einfach ohne jede Überlegung zu rechts- und links-Assoziation aus sich heraus völlig verständlich und eindeutig. Ich brauche auch nicht ellenlange Erläuterungen: "Print druckt aus". Fertig.

    Warum fügt eigentlich + an einen String einen Text an, - nimmt aber nichts weg? Richtig, weil + nämlich in diesem Kontext gar nicht Addition bedeutet, sondern Anhängung. Wieder schwerer zu verstehen. <> vertauscht also? Oder prüft es doch auf Ungleichheit? Wieso kann man das nicht swap nennen? Zu einfach? Und bei Vektoren bedeutet * Skalar- oder Kreuzprodukt? Wieso nenne ich das nicht einfach so? Zu einfach? Ist dotProduct und scalarProduct wirklich so schwer zu lesen, dass man über die Bedeutung von * raten muss?

    Objective-C ist durch und durch dynamisch. C++ ist durch und durch statisch. Das widerspricht sich.
    Entweder ich will die Typsicherheit zur Übersetzungszeit, dann kann ich keine Flexibilität zur Laufzeit haben.
    Entweder ich will die Überprüfung der Vollständigkeit einer Implementierung zur Übersetzungszeit, dann kann ich keine Flexibilität zur Laufzeit haben.

    Übrigens hast du Recht: Du hast in einem anderen Textschnippsel mich vollständig zitiert. Stellt sich nur noch die Frage, warum du dann noch nachgefragt hast. Richtig: Core Data war gemeint. Das geht in Swift nicht, weshalb die Sprache extra für diese Technologie und nur für diese Technologie verwendbar erweitert werden musste (NSManaged). Das heißt, ich kann in Swift keinen entsprechend generelles ORM selbst formulieren, sonst wäre diese Ausnahmeerweiterung ja nicht notwendig. Immerhin: Eine Sprache, die ihre Unfähigkeit bereits bei ihrer Geburt zugibt.

    Warum geht das nicht in Swift? Weil Swift die Fähigkeiten von Objective-C eben nicht unterstützt (und auch gar nicht soll.) Proxys hast du jetzt offenbar auch eingesehen. Warum geht das nicht? Weil Swift die Fähigkeiten von Objective-C eben nicht unterstützt (und auch gar nicht soll).

    Dafür bringt Swift den ganzen Schmerz der Typ-"Sicherheit". (Also die Vermeidung von Gefahren, die es gar nicht gab.) Man kann schon jetzt nicht mehr die Fragen bei SO zu Optionals, Unwrapping, explizit und implizit zählen. Etwas ganz Einfaches, was klaglos funktioniert hat, wird jetzt völlig verkompliziert.
    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:

    Es geht nicht um implizite Bedeutungen. Selbstverständlich ist das innerhalb der Sprache konsistent. "print" et al. versteht indessen jeder. Ganz ohne das Sprachkonzept. Das ist einfach ohne jede Überlegung zu rechts- und links-Assoziation aus sich heraus völlig verständlich und eindeutig. Ich brauche auch nicht ellenlange Erläuterungen: "Print druckt aus". Fertig.

    Und in ein String drucken? sprintf? und in ein File fprintf? Und fprintf(stdout) is das gleiche wie printf? Sehr verständlich ja. Achso, für NSString is es dann aber nichts mehr mit printf sondern NSLog. Achne, stringByAppendingString: oder warte, macht der Argumente?
    C++
  • Selbstverständlich bevorzuge ich (und die üblichen Objective-C-Frameworks) dafür print:… toFile:… usw. Deshalb gibt es ja die Syntax dieser Methodennamen und deshalb ist das in Objective-C möglich. Sehr gut erkannt.

    NSLog() dient einem ganz anderen Zweck. Aber das finde ich in der Tat auch unglücklich und meine Methoden heißen nicht so.
    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"?
  • Ich finde das spannend.
    Wie kann ich denn in einen String drucken? Es heißt doch 'ausdrucken', nicht 'eindrucken'. 'Beeindrucken' und 'eindrücken' gibt es, aber 'eindrucken' kenne ich nicht.
    Er ist schon reichlich rumgekomm' von Hamburch bis nach Brem'. Doch den Ausdruck 'eindrücken', den hat er nie geseh'n.
    (Frei nach: youtube.com/watch?v=FOupWRo31Vg)

    Müsste ich nicht Daten in einen String scannen? Denn 'einscannen' ist mir als Wort durchaus bekannt.
    Aber wo scanne ich diese hinein? Ans Ende? Wäre es dann nicht eher ein Anhängen?
    Ah, -appendString. Ja, das klingt sinnvoller als -print:toString:
    «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

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von Marco Feltmann ()