Swift ist nun OpenSource

  • macmoonshine schrieb:

    Schön, vielleicht hat ja Apple dann auch wieder mehr Zeit, sich um Objective-C zu kümmern. ;) +scnr+
    hoffentlich nicht um es noch mehr zu verschlimmern um die devs endgültig zu swift zu drängen.

    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:

    Naja, wenn ich mir so manche Swift-3.0-Proposals anschaue, dann scheint sich eher Chris Lattner um Swift zu kümmern. :evil:
    Interessant finde ich dabe jai diesen „Nachteil“:

    Chris Lattner schrieb:

    Their expressive advantage is minimal - x++ is not much shorter than x += 1.
    Den Vorteil, dass x++ deutlich schneller und einfacher eingetippt ist als x += 1, interessiert ihn nicht. Aber einfache Benutzbarkeit steht bei Apple ja schon länger nicht mehr an vorderster Stelle.

  • 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.
    Ja, das sieht man auch an diesem Proposal: In Swift 3.0 verändert Apple die Namensübersetzung zu Objective-C extrem stark, so dass zwangsläufig aller 2.x Code bricht. Entweder schaltet man das dann aus oder verwendet das Swift-2.0-zu-3.0-Refactoring. Das wird bestimmt beides ganz toll funktionieren. ;)



    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.
    Ja, deswegen findet sich ja auch dieser Operator in so vielen anderen und unterschiedlichen Programmiersprachen. Er ist halt bequem, praktisch und bekannt. Wer so etwas abschafft, sollte bessere Gründe dafür haben. Abgesehen davon: Warum muss man den überhaupt wieder rausschmeißen? Wer ihn nicht mag, braucht ihn ja nicht zu verwenden.

    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 auch guard else durch unless 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.“

  • Essenchilli schrieb:

    Ich hoffe du hast auf github request erstellt. Diskutieren hin oder her. Melden ist wichtiger oder warum Open Source
    Richtig. Ich überlege mir aber noch, ob ich das mache. Die oben genannten Proposals haben alle schon den Status Accepted; d. h. die Diskussion ist schon gelaufen. Besonders diskussionsfreudig scheint Apple nicht zu sein. :(
    „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:

    Quellcode

    1. //Statt
    2. NSNumber *number = …;// Brauche ich mal kurz
    3. // Wofür?
    4. NSNumber *maximum = …;


    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+
    Kümmern werden sie sich schon noch um Objective-C - so wie um Carbon, den Xserve, Aperture....;-)
    Nach meinem Swift-Vortrag mit Christian meinte ja Tammo zu mir, dass man raunen würde, Swift sei deshalb eingeführt worden, weil Objective-C wegen der Laufzeitumgebung zu langsam für die Watch sei.

    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.
    Ja, deswegen findet sich ja auch dieser Operator in so vielen anderen und unterschiedlichen Programmiersprachen. Er ist halt bequem, praktisch und bekannt. Wer so etwas abschafft, sollte bessere Gründe dafür haben. Abgesehen davon: Warum muss man den überhaupt wieder rausschmeißen? Wer ihn nicht mag, braucht ihn ja nicht zu verwenden.
    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 auch guard else durch unless 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.
    So einfach geht das nicht. Schau etwa hier:

    Apple schrieb:

    Never transform the first selector piece into a Swift keyword,
    Wenn ich jetzt also etwa einen Methodennamen +commonParagraphStyle habe, wird das zu +common, weil common kein Swfit-Schlüsselwort ist.

    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 ()

  • 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.
    Ja, und Apple macht damit auch ganz nebenbei mehrere Millionen Codezeilen überarbeitungsbedürftig.
    „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.
    Ja, und Apple macht damit auch ganz nebenbei mehrere Millionen Codezeilen überarbeitungsbedürftig.
    warum nicht gleich mtp() oder um camel-case beizubehalten mTP()

    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.
    Ja, deswegen findet sich ja auch dieser Operator in so vielen anderen und unterschiedlichen Programmiersprachen. Er ist halt bequem, praktisch und bekannt. Wer so etwas abschafft, sollte bessere Gründe dafür haben. Abgesehen davon: Warum muss man den überhaupt wieder rausschmeißen? Wer ihn nicht mag, braucht ihn ja nicht zu verwenden.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 auch guard else durch unless 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.
    So einfach geht das nicht. Schau etwa hier:

    Apple schrieb:

    Never transform the first selector piece into a Swift keyword,
    Wenn ich jetzt also etwa einen Methodennamen +commonParagraphStyle habe, wird das zu +common, weil common kein Swfit-Schlüsselwort ist.
    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 preist guard else als ganz neues Konstrukt für Fehlerbehandlung an. Dabei ist das nichts anderes, als ein schnödes if else. Ein if not namens unless hatte ja sogar schon Perl von 20 Jahren:

    Quellcode

    1. guard somethingTerribleDoesNotHappen() else { doArmageddon() }
    2. // Perl-Style
    3. unless somethingTerribleDoesNotHappen() { doArmageddon() }
    4. // oder einfach
    5. if somethingTerribleDoesNotHappen() {} else { doArmageddon() }
    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.“