Neulich im Sandkasten

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:

    Type des LValue bestimmt, was an Methoden im RValue ausgeführt wird

    Wow. Gibt es irgend ein Vorteil dafür?

    Kann man dann in Swift auch Funktionen ohne Parameter overloaden? Damit let a : Float = foobar() was anderes ausführt als let b : Double = foobar()? Das wär ja abgedreht. So kann man recht einfach sicherstellen, dass niemand anderes sein Projekt übernehmen kann...
    ♥C++

  • zerm schrieb:

    Kann man dann in Swift auch Funktionen ohne Parameter overloaden? Damit let a : Float = foobar() was anderes ausführt als let b : Double = foobar()? Das wär ja abgedreht.

    Ja geht:

    Quellcode

    1. var f: Float
    2. var d: Double
    4. func foobar() -> Float {
    5. return 2.0
    6. }
    8. func foobar() -> Double {
    9. return 4.0
    10. }
    12. f = foobar()
    13. d = foobar()
    15. println("f = \(f), d = \(d)")
    Alles anzeigen


    zerm schrieb:

    So kann man recht einfach sicherstellen, dass niemand anderes sein Projekt übernehmen kann...

    Und wenn man es richtig geschickt macht, versteht man seinen eigenen Code bald auch nicht mehr.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Michael ()

  • Jepp, das geht, brauchst du aber gar nicht.

    Quellcode

    1. let a : Float = func(x); // es muss eine Methode gefunden werden, die typeof(x) nimmt und Float liefert.
    2. let a: Float = func1(func2(x)) // Es muss ein Methodenpaar gefunden werden, was x nimmt und etwas liefert, so dass eine eine Methode gibt, die das nimmt und Float liefert.
    3. let a: Float = func1(func2(func3(x))) // Es muss ein Methodentripel gefunden werden, was x nimmt und etwas liefert, so dass eine eine Methode gibt, die das nimmt und etwas liefert, wofür es eine Methode gibt, die Float liefert.
    4. let a = func1(func2(func3(x))); // Es muss etwas gefunden werden, was irgendwie sinnvoll ist.


    Das Ganze kann man natürlich noch schön mit (globalen) Operator-Overloading kombinieren. Dann überlädst du ahnungslos + für einen Typen und die gesamte Suche nach den richtigen Methoden kann sich komplett verändern. Überall im Code.

    Es gibt nichts, was so leicht zu lesen ist, wie eine Swift-Source: Man schaut drauf und erkennt sofort, dass es ein riesiger Haufen Scheiße ist.

    Ach, wofür man das braucht? Ich glaube, man muss nur 1 Zeichen tippen statt 7.
    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"?

  • Ach, und ab wann macht man das tolle Feature Type-Inference nicht mehr? let a = b + c + d? Ist das bereits zu komplex, um kaputt zu gehen? (Ja.)

    "Use sparingly" ist ja schon eine dämliche Einschränkung. Das nimmt allerdings bei Swift überhand, so dass man dann zu einem "Use Swift sparingly" kommt.
    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"?

  • zerm schrieb:

    Michael schrieb:

    Ja geht:

    Amin Negm-Awad schrieb:

    Jepp, das geht, brauchst du aber gar nicht.


    Wenn ich dann nur var x = foobar() mache, welches ("was irgendwie sinnvoll ist") wird denn dann genommen? Ist das definiert, oder Glückssache?
    Du musst unseren Vortrag auf der Macoun sehen.

    Er macht nur weiter, wenn er genau eine Lösung findet. Was natürlich ebenfalls lustig ist, wenn du ein foo() hinzufügst. Auch hier kann dir potentiell der gesamte Code kaputt gehen. Man merkt es wenigstens nur. (Swift soll ja mehr Fehler zur Übersetzungszeit finden. Tut es dann ja auch. War das wirklich genau so gedacht?)
    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"?

  • Habe das hier heute zufällig gefunden...

    nussratte schrieb:

    ich verstehe zwar das diese sachen alle nicht gut sind, aber fällt das nicht alles in die Kategorie

    man kann es machen, man muss oder besser man sollte es nicht machen?
    So sehe ich das auch. Nur weil es _geht_ muss man es ja nicht machen.
    Wenn man seine Software vernünftig "designed", sollten die meisten dieser Probleme hier nicht auftreten.
    Swift gibt einem halt große "Freiheiten", aber man muss damit auch umgehen können...

    Ist aber natürlich nur meine Meinung. Ich entwickle seht gerne in Swift und finde, damit kann sehr wohl gute und auch sehr leserliche Software entwickeln...

  • Butterkeks schrieb:

    Amin Negm-Awad schrieb:

    Du musst unseren Vortrag auf der Macoun sehen.
    Hab schon öfter hier von diesen Vortrag gelesen, gibt es denn derzeit eine Möglichkeit sich den irgendwo anzusehen?
    Noch nicht. Aber sobald die online gehen, im Archiv und im Podcast der Macoun.

    kmr schrieb:

    Butterkeks schrieb:

    Hab schon öfter hier von diesen Vortrag gelesen, gibt es denn derzeit eine Möglichkeit sich den irgendwo anzusehen?
    Das ist eine sehr gute Frage, der ich mich direkt anschließe. Chris? Thomas?
    Die haben gerade eine niedrigere Priorität, als die Schlacht zur Vorbereitung der Macoun 2015.

  • Ich habe da noch etwas Offtopic im Kopf, für das ich nicht extra einen Thread eröffnen möchte.
    Mal schauen, ob ich den Gedankengang verständlich ausdrücken kann.

    Kennt eigentlich noch jemand AppleScript Studio.
    Ich habe vor fast 20 Jahren mit AppleScript begonnen und bin dann zu AppleScript Studio angelangt, den damit konnte auf OS X eine vollwertige Anwendung erstellt werden, ohne richtig programmieren zu können.
    Viele Dinge wurden im Hintergund dem Entwickler abgenommen und das Ergebnis war das Gleiche, als wäre das Ding mit Objective-C getackert.
    Apples Beweggrund mit dieser "Programmiersprache" war Leute für die Entwicklung zu begeistern, da es so einfach sei.
    Zu 10.5 oder so wurde das dann aber eingestellt.

    Bei 10.6 hat Apple dann AppleScriptObjC eingeführt.
    Das war sogar ein eigenständiger Projekt-Typ im Xcode.
    Auch da wollte Apple die Brücke von Einfachheit zur Programmierung bauen.
    Die Sprache gibt es zwar noch, aber es wird nichts mehr beworben und der Support scheint auch auszulaufen.

    Swift scheint mir auch so etwa zu sein.
    Gravierender Unterschied ist halt, dass es auch mit der mobilen Plattform funktioniert.

    Viele Grüße