Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von helmut72 ()
Swift ist nun OpenSource
Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen
-
-
Schön, vielleicht hat ja Apple dann auch wieder mehr Zeit, sich um Objective-C zu kümmern. +scnr+„Meine Komplikation hatte eine Komplikation.“
-
macmoonshine schrieb:
Schön, vielleicht hat ja Apple dann auch wieder mehr Zeit, sich um Objective-C zu kümmern. +scnr+
hab gelesen dass C++ interoperability nicht so schnell (wenn überhaupt) kommen wird, also ist swift schon mal für die größten meiner obj-c projekte nicht anwendbar... -
macmoonshine schrieb:
Schön, vielleicht hat ja Apple dann auch wieder mehr Zeit, sich um Objective-C zu kümmern. +scnr+
-
t-no schrieb:
macmoonshine schrieb:
Schön, vielleicht hat ja Apple dann auch wieder mehr Zeit, sich um Objective-C zu kümmern. +scnr+
„Meine Komplikation hatte eine Komplikation.“ -
Naja, wenn ich mir so manche Swift-3.0-Proposals anschaue, dann scheint sich eher Chris Lattner um Swift zu kümmern.„Meine Komplikation hatte eine Komplikation.“
-
macmoonshine schrieb:
Naja, wenn ich mir so manche Swift-3.0-Proposals anschaue, dann scheint sich eher Chris Lattner um Swift zu kümmern.
Chris Lattner schrieb:
Their expressive advantage is minimal - x++ is not much shorter than x += 1.
-
Die Prefix- und Postfix-Inkrementoperationen sieht man nun ja nicht selten als Inline-Operationen (z. B.
theArray[i++]
). Da wird eine ganz schöne Menge Code und deren Programmierer brechen.
Michael schrieb:
Aber einfache Benutzbarkeit steht bei Apple ja schon länger nicht mehr an vorderster Stelle.
Ich habe bei Lattner inzwischen den Eindruck, der will ein schönes Swift-Schloss bauen und schert sich nicht die Bohne um die ständigen Migrationsaufwände, die bei den Swift-Programmieren entstehen.„Meine Komplikation hatte eine Komplikation.“ -
Michael schrieb:
Den Vorteil, dass x++ deutlich schneller und einfacher eingetippt ist als x += 1, interessiert ihn nicht.
Wenn man überflüssigen Ballast aus Swift entfernen möchte, böten sich bessere Kandidaten (z. B. Verzweigungsoperatoren und -anweisungen) an, bzw. könnte man auchguard else
durchunless
ersetzen. Das würde dann nicht so hochtrabend klingen und dann würde dieses unnötige Konstrukt wenigstens noch für andere Aufgaben sprachlich sinnvoll sein.„Meine Komplikation hatte eine Komplikation.“ -
@macmoonshine
Ich hoffe du hast auf github request erstellt. Diskutieren hin oder her. Melden ist wichtiger oder warum Open Source
Nochmal Apple braucht die Community. -
Essenchilli schrieb:
Ich hoffe du hast auf github request erstellt. Diskutieren hin oder her. Melden ist wichtiger oder warum Open Source
„Meine Komplikation hatte eine Komplikation.“ -
Ein Riesendokument mit wasweißichwieviel Regeln, um Methodennamen abzukürzen. Großartig, eine echte Hilfe.
Jetzt muss ich nicht mehr moveToPoint() schreiben, sondern moveTo(). Was mir das die Arbeit erleichtert, vor allem, wenn man bedenkt, dass man ja nur mov tippen musste, um dann aus dem Pop-Up auszuwählen.
Ich hatte bei Objective-Cloud das Problem, dass ich die Argumenttypen nicht kannte. (Liefert die Laufzeit nicht.) Im ersten Ansatz hatte ich deshalb immer eine Typisierungsfunktion typesOf_Methodenname. Dann dachte ich darüber nach, aus dem Methodennamen den Typen zu inferieren, etwa addMember:toGroup:, wenn es die Klassen Member und Group gab mit dem Ergebnis, dass man add:to: schreiben kann.
Dann bemerkte ich, was für ein unnötiger, komplizierter Schwachsinn das ist und habe die clang Tools angeworfen.
Übrigens lässt sich Typgestottere am besten vermeiden, wenn man bei der Namenswahl gerade bei "Zwischenvariablen" nachdenkt. Kam auch im Vortrag vor:
Könnte übrigens auch Apple mal ohne einen Riesenaufwand an Regeln, die ich über viele Seiten erläutern muss sein lassen. -addObject: (NSArray) ist in etwa so sinnvoll wie ein Methodenname executeMethodAddObject:. Es enthält Überflüssiges, weil man stets Objekte einem Array hinzufügt. Aber das ist auch umgekehrt so etwas von unwichtig …
Übrigens: Wenn man so einen Riesenaufwand betreibt, um Name-Mapping von Objective-C nach Swift zu betreiben, ist das der beste Beleg dafür, dass Swift nicht Objective-C verdrängt. Denn dann könnte man einfach nach und nach die Namen an Swift anpassen.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 5 mal editiert, zuletzt von Amin Negm-Awad ()
-
t-no schrieb:
macmoonshine schrieb:
Schön, vielleicht hat ja Apple dann auch wieder mehr Zeit, sich um Objective-C zu kümmern. +scnr+
Irgendwann zähle ich mal diese "Ich wünsche es mir so sehr, dass es bestimmt auch stimmt"-Märchen. Bei meiner Tochter lassen übrigens gerade diese Wunsch-Wahrheit-Verwechslungen nach. Aber die ist jetzt auch schon 5 Jahre alt.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:
Michael schrieb:
Den Vorteil, dass x++ deutlich schneller und einfacher eingetippt ist als x += 1, interessiert ihn nicht.
Wenn man überflüssigen Ballast aus Swift entfernen möchte, böten sich bessere Kandidaten (z. B. Verzweigungsoperatoren und -anweisungen) an, bzw. könnte man auchguard else
durchunless
ersetzen. Das würde dann nicht so hochtrabend klingen und dann würde dieses unnötige Konstrukt wenigstens noch für andere Aufgaben sprachlich sinnvoll sein.
Apple schrieb:
Never transform the first selector piece into a Swift keyword,
Wird später common als Schlüsselwort eingeführt, muss die Methode entweder dann doch wieder +commonParagraphStyle: heißen oder ich muss meine Sourcen mit Backticks versehen, was dann wohl die Übernahme moderner Sprachfeatures aus SQL ist. Vielleicht findet sich bei ALGOL-68 ja noch etwas Modernes, was sich für Swift eignet. Ausschließen würde ich es nicht.
Entschuldigung: Wer solche Namenstransformationsregeln einführt, muss wirklich als Baby ganzjährig mit dem Klammerbeutel gepudert worden sein. Das ist dermaßen knackedumm, dass es mir die Sprache verschlägt. Und wozu? Man spart ein paar Tastendrücke und macht den Code obfuscated.
Doug: "Dave, ich habe eine tolle Idee: …!"
Dave: "Das klingt total kewl, das machen wir, Doug"
Irgendwer: "Sollten wir nicht nachdenken, ob sich das durchhalten lässt?"
Dave: "Welchen Teil von <kewl> genau hast du denn jetzt nicht verstanden?"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 ()
-
macmoonshine schrieb:
Schön, vielleicht hat ja Apple dann auch wieder mehr Zeit, sich um Objective-C zu kümmern. +scnr+
Das klingt doch ganz gut ;-), oder nicht? Mich freut es zumindest. -
Amin Negm-Awad schrieb:
Jetzt muss ich nicht mehr moveToPoint() schreiben, sondern moveTo(). Was mir das die Arbeit erleichtert, vor allem, wenn man bedenkt, dass man ja nur mov tippen musste, um dann aus dem Pop-Up auszuwählen.
„Meine Komplikation hatte eine Komplikation.“ -
macmoonshine schrieb:
Amin Negm-Awad schrieb:
Jetzt muss ich nicht mehr moveToPoint() schreiben, sondern moveTo(). Was mir das die Arbeit erleichtert, vor allem, wenn man bedenkt, dass man ja nur mov tippen musste, um dann aus dem Pop-Up auszuwählen.
da spart man den platz ein welchen man wieder verliert da man ++ und -- umschreiben muss... -
Amin Negm-Awad schrieb:
macmoonshine schrieb:
Michael schrieb:
Den Vorteil, dass x++ deutlich schneller und einfacher eingetippt ist als x += 1, interessiert ihn nicht.
guard else
durchunless
ersetzen. Das würde dann nicht so hochtrabend klingen und dann würde dieses unnötige Konstrukt wenigstens noch für andere Aufgaben sprachlich sinnvoll sein.
Apple schrieb:
Never transform the first selector piece into a Swift keyword,
Wird später common als Schlüsselwort eingeführt, muss die Methode entweder dann doch wieder +commonParagraphStyle: heißen oder ich muss meine Sourcen mit Backticks versehen, was dann wohl die Übernahme moderner Sprachfeatures aus SQL ist. Vielleicht findet sich bei ALGOL-68 ja noch etwas Modernes, was sich für Swift eignet. Ausschließen würde ich es nicht.
Entschuldigung: Wer solche Namenstransformationsregeln einführt, muss wirklich als Baby ganzjährig mit dem Klammerbeutel gepudert worden sein. Das ist dermaßen knackedumm, dass es mir die Sprache verschlägt. Und wozu? Man spart ein paar Tastendrücke und macht den Code obfuscated.
Doug: "Dave, ich habe eine tolle Idee: …!"
Dave: "Das klingt total kewl, das machen wir, Doug"
Irgendwer: "Sollten wir nicht nachdenken, ob sich das durchhalten lässt?"
Dave: "Welchen Teil von <kewl> genau hast du denn jetzt nicht verstanden?"
Ich habe aber nicht von Selektoren sondern Schlüsselwörtern geredet. Apple preistguard else
als ganz neues Konstrukt für Fehlerbehandlung an. Dabei ist das nichts anderes, als ein schnödesif else
. Einif not
namensunless
hatte ja sogar schon Perl von 20 Jahren:
Das mag ja manchmal ganz praktisch sein, um zu viele Negationen oder Klammern in Bedingungen zu vermeiden. Dann sollte man es aber auch danach nennen, was es tut und keine zusätzliche Fehlerbehandlungsmystik hineinsuggerieren.„Meine Komplikation hatte eine Komplikation.“ -
... und es geht immer weiter: github.com/apple/swift-evoluti…move-c-style-for-loops.md
Erst eine Sprache einzuführen und danach grundlegend umzukrempeln, hört sich nach einem richtig guten Plan an.„Meine Komplikation hatte eine Komplikation.“ -
Ich verstehe auch nicht warum man irgendwelche features implemnteirt um sie dann wirklich grundlos nach zwei jahren wieder zu entfernen und so alten code inkompatibel zu machen. Was verspricht sich apple davon? Das ist doch nur Gängelung der Entwickler und sonst nichts!