Swift-evolution

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

  • Swift-evolution

    Nimmt eigentlich ein nennenswerter Prozentsatz der Anwesenden an der Zukunft unserer zukünftigen Programmiersprache teil? (sprich: List die entsprechende Mailingliste)
    Das Schicksal von for und i++ wurde afair ja mal kurz angeschnitten, aber auch sonst gibt es einige Vorschläge, die dem einem oder anderen hellhörig machen könnten:
    Momentan (also eigentlich schon ziemlich lange) wird darüber debattiert, Vererbung per default zu verbieten... dann muss man am Ende noch Objective-C nehmen, um doch noch eine Unterklasse zu generieren ;)

  • Meine Vorschläge:
    1. Ich würde am besten direkt diesen ganzen objektorientieren Schnickschnack unterbinden. Der Kram ist schließlich schon über 40 Jahre alt und steht dem Fortschritt nur im Weg.
    2. Namen stören die Unlesbarkeit des Codes ungemein, weswegen alle Buchstaben, Ziffern, Silbenzeichen usw. in Methodennamen verbieten sollte.
    3. Der +-Operator ist übrigens auch überflüssig, da sich problemlos durch das binäre und unäre Minus ersetzen lässt.
    4. Es gibt viel zu wenige Möglichkeiten für Bedingungen in Swift: Ich schlage die Einführung von when, perhaps, in the case of sowie des tertiären Operators ¿:? vor.
    „Meine Komplikation hatte eine Komplikation.“

  • Link: lists.swift.org/pipermail/swif…-Mon-20151207/000871.html

    Mich würde die Begründung auch interessieren - aber die ist echt schwer zu finden ;)
    Nur ums vorher klarzustellen: Vererbung soll es natürlich weiterhin geben, aber nur von Klassen, die das ausdrücklich erlauben

    macmoonshine schrieb:

    Ich würde am besten direkt diesen ganzen objektorientieren Schnickschnack unterbinden. Der Kram ist schließlich schon über 40 Jahre alt und steht dem Fortschritt nur im Weg.
    Na ja, Objektorientierung ist schon noch ein bisschen mehr als Vererbung... und funktionale Programmierung ist wahrscheinlich noch älter, und trotzdem fliegen die Hipster drauf ;)

  • t-no schrieb:

    Link: lists.swift.org/pipermail/swif…-Mon-20151207/000871.html
    Oh, da stehen uns ja echt güldene Java-Zeiten bevor: Eine Einschränkung ohne Not, die davon ausgeht, dass der Klassenentwickler bereits eine perfekte Klasse geschaffen hat, die bereits alle denkbaren Anwendungsfälle abdeckt. Das führt dann in der Praxis meistens dazu, dass man selbst für kleinste Anpassungen an einer Klasse direkt das komplette Framework neu entwickeln muss.
    „Meine Komplikation hatte eine Komplikation.“

  • Herrjee. Da geht schon sofort das swift-Bashing los, ohne vorher einmal Luft zu holen und nachzudenken...

    Worum geht es denn? Der Standard-Ist-Zustand:

    Quellcode

    1. class A {
    2. var a = "A"
    3. }
    4. class B: A {
    5. var b = "B"
    6. }
    7. let x = B().a
    8. print(x)
    9. // A

    Vererbung wie bekannt und gewohnt.
    Ein Programmierer kann allerdings über das Keyword final auch heute schon Klassen als abschließend nicht mehr vererbbar deklarieren. Das sieht dann so aus:

    Quellcode

    1. final class A {
    2. var a = "A"
    3. }
    4. class B: A {
    5. var b = "B"
    6. }
    7. let x = B().a
    8. print(x)
    9. // final.swift:4:7: error: inheritance from a final class 'A'
    10. // class B: A {
    11. // ^
    Alles anzeigen

    Andere API-Anbieter können also heute schon, wenn sie es denn wollen, ihre Klassen als nicht mehr vererbar definieren. Normalerweise tun sie es nicht, eben um deren API auch für die Vererbbarkeit weiter verwertbar zu halten. Über seinen eigenen Code ist man ja sowieso Herr.
    Warum gibt es diese Möglichkeit überhaupt? Weil der Compiler dadurch einiges an Optimierungen vornehmen kann. Der ganze self-super-shlepp ist abschließend aufgelöst, Runtime-Overhead kann entfallen.

    Jetzt stellt sich heraus, daß swift in der Praxis über class extensions, Protokolle, protocol extensions, generic protocols, etc. hierarchisch eigentlich sehr flach ist. Von eigenen Klassen werden nur noch selten weitere Unterklassen abgeleitet. Wenn fremde Klasen, wie z.B. NSView, abgeleitet werden, legt man davon idR auch nur noch in den allerseltesten Fällen weitere Unterklassen an. Normalerweise würde man also vermutlich 95% seiner Klassen als 'final' deklarieren. Macht aber kaum einer.

    Was liegt also näher, als nicht wenigstens einmal darüber nachzudenken, ob man dieses Optimierungspotenzial nicht standardgenäß haben möchte? Stattdessen dann eben durchschnittlich nur noch vermutlich 5% seiner Klassen als subclassable oder inheritable oder was auch immer zu deklarieren.

    Ich selber habe mir darüber noch kein abschließendes Urteil gebildet. Ich stehe dem aber offen gegenüber. Zumindest kann ich hier erkennen, daß und wie ein Vorteilsgewinn erreicht werden soll. Bei der Abschaffung der C-Style-Loops und des Inkrements und Dekrements kann ich nicht sehen, wie da irgendwie ein Vorteil eine Rolle gespielt haben soll.

    Und dabei belasse ich es, sonst komme ich selber auch noch ins swift-Bashing...^^

    Edit: Doch ein Bashing hätte ich da. Weil's so schön ist. Ein freier Codeverbesserer der Community springt in die Bresche, tauscht C-Style-For-Loops in der Swift-stdlib gegen anderen Swift-Standard-Code und 'ner while-Loop aus. Genau das, was alle jetzt machen sollen. Apple dann so: "This needs review from the performance team." Ja, Ihr Torfpfosten! Hättet Ihr nicht mal vorher gucken können, ob das Auswirkungen auf die Performance hat!? :D
    github.com/apple/swift/pull/742#issuecomment-166798814

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von torquato ()

  • Die Idee, keine Vererbung zu haben, habe ich schon beim "Late NIght Talk" auf der Macoun genannt und lässt sich problemlos in Objective-C verwirklichen. (Da kommt bloß niemand auf den abstrusen Gedanken, Vererbung zu verbieten.) Hat wohl mal wieder niemand zugehört … Dabei habe ich doch extra den neben mir sitzenden gefragt, warum er von UIDocument ableitet. Er wusste es nicht so genau.

    Wozu dient Vererbung? Eigentlich wird damit ein Interface übernommen, möglicherweise erweitert, sowie eine Implementierung – wenn ich nicht überschreibe.

    Wenn ich nun ein Interface auf andere Weise übernehmen kann, etwa weil ich jedes Interface als Protokoll ansehe – eine Idee, die ich schon lange für Objective-C habe, das wegen seiner Dynamik dafür besonders geeignet ist –, so brauche ich dafür keine Vererbung. In etwa in Objective-C:

    Quellcode

    1. @interface MyClass : NSObject // An Interface is a protocol
    2. …
    3. @end
    5. @interface MyFormerSubclass : NSObject<MyClass> // Ich erbe nicht von MyClass, sondern übernehme das Interface
    6. …
    7. @end


    Das macht keinen Unterschied. Alle noch einmal eine ganz alte Auflage von mir aus dem Regal nehmen und das Sekretärinnenbeispiel lesen: Es kommt nicht darauf an, was etwas ist (Typ), sondern darauf, was etwas kann. Wenn es auf den Typen nicht ankommt, kann es auch auf Vererbung nicht ankommen.

    Bleibt also die Implementierung übrig. Da habe ich bei Vererbung den Vorteil, Code aus der Basisklasse zu übernehmen. Man lernt: Vererbung ist ein Mittel des Implementierungs-Reuse, nicht des Interface-Reuse.

    Implementierungen kann ich aber auch anders übernehmen, etwa über einen Member. Oder über ein zusätzliches Schlüsselwort.

    Wie ich aber schon im Sekretärinnenbeispiel schrieb: Auch wenn Interface und Implementierung zwei völlig verschiedene Paar Schuhe bei der Vererbung sind, so erleichtert Vererbung mir eben die Implementierung ungemein. Es ist eine Frage der Einfachheit der Implementierung.

    Deshalb sind in der Tat Klassenbäume häufig zu tief, weil der Programmierer immer daran denkt, was ein Ding können soll, anstatt darüber nachzudenken, wie er es implementiert. Er vermischt die beiden Fragen.

    Aber dafür braucht man kein neues Sprachkonzept, dass die Sache mal wieder nur komplizierter macht, als sie ist. Und häufig unbequemer.

    Man braucht Programmierer, die gute Bücher lesen und verstehen. ;)
    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"?

  • tsunamix schrieb:

    Warum gibt es diese Möglichkeit überhaupt? Weil der Compiler dadurch einiges an Optimierungen vornehmen kann.
    Das Ding ist aber: Das Argument wird in der Diskussion überhaupt nicht bemüht - und dass zurecht, denn das bisschen Performance-Gewinn spielt so ziemlich gar keine Rolle; oder muss jemand regelmäßig von Objective-C auf pures C wechseln, damit der Compiler inlinen kann?

  • t-no schrieb:

    tsunamix schrieb:

    Warum gibt es diese Möglichkeit überhaupt? Weil der Compiler dadurch einiges an Optimierungen vornehmen kann.
    Das Ding ist aber: Das Argument wird in der Diskussion überhaupt nicht bemüht - und dass zurecht, denn das bisschen Performance-Gewinn spielt so ziemlich gar keine Rolle; oder muss jemand regelmäßig von Objective-C auf pures C wechseln, damit der Compiler inlinen kann?
    Nicht regelmäßig, ist aber schon vorgekommen. Trotzdem hast du Recht, dass das kein Grund sein sollte, denn erstens bringen solche Optimierungen ja eigentlich nur auf absolut unterster Ebene etwas und zweitens könnte ich die Klasse ja in diesem Fall final setzten. Ich find's ja auch richtig, dass Vererbung allgemein überbewertet ist, aber deshalb etwas per default deaktivieren?

    Soll das so eine Pascalartige Oberlehrer-Bevormundungssprache werden, bei der mir die Sprache permanent erklären will, was ihre Vorstellung von schön und richtig ist?

    Aber eigentlich finde ich etwas anderes daran schade: Eine regelmäßige Sprachevolution in allen Ehren, aber wenn permanent an solchen Kernaspekten der Sprache herumgefummelt wird, ist das für mich als Brot-und-Butter-Sprache keine Option. Es geht halt nicht, dass Sprachänderugen permanent existierenden Code brechen. Darüber kann auch kein automatisches Refactoring hinwegtäuschen.
    Multigrad - 360°-Produktfotografie für den Mac

  • tsunamix schrieb:

    Normalerweise tun sie es nicht, eben um deren API auch für die Vererbbarkeit weiter verwertbar zu halten.
    Das ist ja genau das Problem: Indem man die Logik umkehrt, wird es zum Standard. Die meisten Programmierer vergessen ihre Klassen freizugeben.

    Ein vergessenes virtual in C++ nervt schon ungemein.

    Ein Java-Beispiel: Die alten JDKs hatten keine Möglichkeit, für HTTP-Anfragen die Timeouts zu ändern. Das hätte man durch Subclassing leicht beheben können. Leider war der entsprechende Code aber hinter so vielen finalen Klassen und Methoden versteckt, dass man fast das ganze HTTP-URL-Handling neu implementieren musste. Solche Probleme hatte ich im Vor-Swift-Cocoa bislang noch nicht.

    tsunamix schrieb:

    Normalerweise würde man also vermutlich 95% seiner Klassen als 'final' deklarieren. Macht aber kaum einer.
    Ja, wenn man das Reserverad aus dem Auto entfernt, spart ich Einiges an Sprit. Macht aber kaum einer. POITROAE scheint die Philosophie von Swift zu sein.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    POITROAE scheint die Philosophie von Swift zu sein.
    Zumindest an dem final-Beispiel kann man das aber nicht fest machen:
    Gut möglich, dass "nur ein paar Theoretiker mit zu viel Zeit" eine öffentliche Liste fluten, und das Kernteam am Ende nur den Kopf schüttelt und alles lässt wie es ist... ist alles überhaupt nicht absehbar, aber immerhin war ja die erste Entscheidung, final nur als Option anzubieten.

  • t-no schrieb:

    macmoonshine schrieb:

    POITROAE scheint die Philosophie von Swift zu sein.
    Zumindest an dem final-Beispiel kann man das aber nicht fest machen:Gut möglich, dass "nur ein paar Theoretiker mit zu viel Zeit" eine öffentliche Liste fluten, und das Kernteam am Ende nur den Kopf schüttelt und alles lässt wie es ist... ist alles überhaupt nicht absehbar, aber immerhin war ja die erste Entscheidung, final nur als Option anzubieten.
    Naja, wenn ich mir die weiteren Beiträge in dem Thread ansehe, sind die weiteren Vorschläge noch schlimmer. ;)
    „Meine Komplikation hatte eine Komplikation.“

  • mattik schrieb:

    Es geht halt nicht, dass Sprachänderugen permanent existierenden Code brechen. Darüber kann auch kein automatisches Refactoring hinwegtäuschen.
    Bei so einer Änderung kann dann aber auch kein Refactoring mehr helfen. Wenn Apple demnächst die Klasse XY (versehentlich) als nicht mehr als ableitbar deklariert, kann auch das beste Tool nicht mehr helfen. Wenn dann König Kunde nur mal schnell einen Text in seinem Uralt-Projekt angepasst haben will, dauert diese Anpassung dann schnell mal eine Woche.

    Schon bei den Nullable-Deklarationen haben die an einigen Stellen geschlampt, und Parameter in den Objective-C-Headern nicht als nonnull deklariert, obwohl die Doku nil ausdrücklich erlaubt.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    Schon bei den Nullable-Deklarationen haben die an einigen Stellen geschlampt, und Parameter in den Objective-C-Headern nicht als nonnull deklariert, obwohl die Doku nil ausdrücklich erlaubt.
    Auch den umgekehrten Fall gibt es, was ja noch viel schlimmer ist. Parameter als _Nullable deklariert und in der Erklärung der Parameter direkt darunter steht „This parameter must not be nil“.

    Zum Thema selbst. Es ist halt auch ein Nachteil der Open Source Geschichte, dass jeder seine persönlichen Vorlieben am liebsten zum Standard erheben möchte. Ich hoffe nur, dass Apple da nicht den Faden verliert und Swift durch Umsetzung solcher, in meinen Augen sinnlosen Vorschlägen, endgültig gegen die Wand fährt. Ich finde es ja schon bemerkenswert, dass eine Version 3.0 immer noch keine Sourcecode Kompatibilität bringen soll. Da kann man Swift doch immer noch nicht produktiv nutzen, bzw. man muss schon ein wenig Mut haben. Ich kenne da jemanden, dem ist mit Schrecken aufgefallen, dass er für seine App zur Zeit nicht mal eben schnell einen Bugfix liefern könnte, weil sie noch in Swift 1.2 geschrieben ist. Er müsste die erst mal auf Swift 2.0 heben, was aber eben doch nicht einfach per Knopfdruck gemacht ist.

  • Michael schrieb:

    macmoonshine schrieb:

    Schon bei den Nullable-Deklarationen haben die an einigen Stellen geschlampt, und Parameter in den Objective-C-Headern nicht als nonnull deklariert, obwohl die Doku nil ausdrücklich erlaubt.
    Auch den umgekehrten Fall gibt es, was ja noch viel schlimmer ist. Parameter als _Nullable deklariert und in der Erklärung der Parameter direkt darunter steht „This parameter must not be nil“.
    Zum Thema selbst. Es ist halt auch ein Nachteil der Open Source Geschichte, dass jeder seine persönlichen Vorlieben am liebsten zum Standard erheben möchte. Ich hoffe nur, dass Apple da nicht den Faden verliert und Swift durch Umsetzung solcher, in meinen Augen sinnlosen Vorschlägen, endgültig gegen die Wand fährt. Ich finde es ja schon bemerkenswert, dass eine Version 3.0 immer noch keine Sourcecode Kompatibilität bringen soll. Da kann man Swift doch immer noch nicht produktiv nutzen, bzw. man muss schon ein wenig Mut haben. Ich kenne da jemanden, dem ist mit Schrecken aufgefallen, dass er für seine App zur Zeit nicht mal eben schnell einen Bugfix liefern könnte, weil sie noch in Swift 1.2 geschrieben ist. Er müsste die erst mal auf Swift 2.0 heben, was aber eben doch nicht einfach per Knopfdruck gemacht ist.
    Darf man mit Swift 1.2 geschriebene Apps nicht mehr submitten?

  • t-no schrieb:

    tsunamix schrieb:

    Warum gibt es diese Möglichkeit überhaupt? Weil der Compiler dadurch einiges an Optimierungen vornehmen kann.
    Das Ding ist aber: Das Argument wird in der Diskussion überhaupt nicht bemüht - und dass zurecht, denn das bisschen Performance-Gewinn spielt so ziemlich gar keine Rolle; oder muss jemand regelmäßig von Objective-C auf pures C wechseln, damit der Compiler inlinen kann?
    Ich glaube schon länger, dass das keine Rolle spielt. Es geht nicht darum, eine für den Programmierer gut verwendbare Sprache zu schaffen. Es geht darum, was ein Compilerbauer als Maximum an "abstrakter Schönheit" aus einer Sprachdefinition herausholen kann.

    Kann man ja auch machen. Man sollte dann bloß nicht den Leuten erzählen, dass sie damit leicht und schnell Software entwickeln können.
    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"?

  • mattik schrieb:

    Soll das so eine Pascalartige Oberlehrer-Bevormundungssprache werden, bei der mir die Sprache permanent erklären will, was ihre Vorstellung von schön und richtig ist?
    Gerade feiern wir die Geburt unseres Erretters und du nennst Jesus Chris Lattner einen Oberlehrer? Preise den Erlöser, du Pharisäer, dein Heiland ist dir geboren. Und wehe, du weichst von den Lehren ab. Schon aus der Ferne wirst du den Clang der Pferde der heiligen spanischen Inquisition hören. (Wird mal wieder Zeit, dass man einen Nubbel verbrennen kann.)

    Hey, endlich keine ellenlangen Flamewar mehr, ob Foo*bar, Foo* bar, Foo *bar oder Foo * bar die einzig heilsbringende Lehre ist.

    Lobe den Herren,
    der alles so herrlich regieret,
    der dich auf Adelers
    Fittichen sicher geführet,
    der dich erhält,
    wie es dir selber gefällt;
    hast du nicht dieses verspüret?

    Andererseits sollte man den anwachsenden Haufen Scheiße auch nicht erhöhen.

    Swift lässt sich eher mit einer untersetzen Teilzeitdomina aus Wanne-Eickel vergleichen.
    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:

    Michael schrieb:

    macmoonshine schrieb:

    Schon bei den Nullable-Deklarationen haben die an einigen Stellen geschlampt, und Parameter in den Objective-C-Headern nicht als nonnull deklariert, obwohl die Doku nil ausdrücklich erlaubt.
    Auch den umgekehrten Fall gibt es, was ja noch viel schlimmer ist. Parameter als _Nullable deklariert und in der Erklärung der Parameter direkt darunter steht „This parameter must not be nil“.Zum Thema selbst. Es ist halt auch ein Nachteil der Open Source Geschichte, dass jeder seine persönlichen Vorlieben am liebsten zum Standard erheben möchte. Ich hoffe nur, dass Apple da nicht den Faden verliert und Swift durch Umsetzung solcher, in meinen Augen sinnlosen Vorschlägen, endgültig gegen die Wand fährt. Ich finde es ja schon bemerkenswert, dass eine Version 3.0 immer noch keine Sourcecode Kompatibilität bringen soll. Da kann man Swift doch immer noch nicht produktiv nutzen, bzw. man muss schon ein wenig Mut haben. Ich kenne da jemanden, dem ist mit Schrecken aufgefallen, dass er für seine App zur Zeit nicht mal eben schnell einen Bugfix liefern könnte, weil sie noch in Swift 1.2 geschrieben ist. Er müsste die erst mal auf Swift 2.0 heben, was aber eben doch nicht einfach per Knopfdruck gemacht ist.
    Darf man mit Swift 1.2 geschriebene Apps nicht mehr submitten?
    Dürfen ist eine Frage des Könnens. Kann man noch mit Xcode Versionen kleiner 7 submitten?