Unklarheiten zu Swift

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

  • Unklarheiten zu Swift

    Liebe Community,

    ich lese mich gerade in Swift ein und finde die Sprache eigentlich ziemlich super, einzig allein die Syntax finde ich etwas gewöhnungsbedürftig, obwohl ich mich auch schon daran gewöhnt habe, aber die Syntax von Objective-C finde ich nach wie vor schöner.

    Ich habe mir beim Lernen ein paar Fragen zu diverser Unklarheiten zusammengeschrieben und hoffe, dass ihr mir die Antworten darauf liefern könnt.
    • Sind Funktionen und Methoden das gleiche, nur dass Methoden an Klassen, Structs und Enums gerichtet sind?
    • Und was genau sind Types? Sind das Klassen, oder Klassen zusammen mit Doubles, Ints, Strangs, etc?
    • Eine typische Klassenmethode wird in Swift als Type Method bezeichnet, richtig?
    • Ist Swift weniger objektorientiert, da Strings, Arrays und Dictionarys streng genommen keine Objekte im Sinne einer Instanz mehr sind?

    Mit freundlichen Grüßen

    TheFuriousLion
  • TheFuriousLion schrieb:

    finde die Sprache eigentlich ziemlich super, einzig allein die Syntax finde ich etwas gewöhnungsbedürftig

    +roflcopter+

    Alle finden Swift sooo toll, aber keiner weiß warum eigentlich. ;)

    TheFuriousLion schrieb:

    Sind Funktionen und Methoden das gleiche, nur dass Methoden an Klassen, Structs und Enums gerichtet sind?

    Ja, das ist aber im Prinzip in allen Sprachen so, die klassenbasierte Objektorientierung unterstützen.

    TheFuriousLion schrieb:

    Ist Swift weniger objektorientiert, da Strings, Arrays und Dictionarys streng genommen keine Objekte im Sinne einer Instanz mehr sind?

    Wie misst Du Objekt-Orientierung? Wieso sind Strings, Arrays und Dictionarys keine Objekte? Was meinst Du mit im Sinne einer Instanz?
    „Meine Komplikation hatte eine Komplikation.“
  • TheFuriousLion schrieb:


    ich lese mich gerade in Swift ein und finde die Sprache eigentlich ziemlich super, einzig allein die Syntax finde ich etwas gewöhnungsbedürftig, obwohl ich mich auch schon daran gewöhnt habe, aber die Syntax von Objective-C finde ich nach wie vor schöner.


    Japp, ich finde die von Obj-C auch schöner...

    TheFuriousLion schrieb:

    Sind Funktionen und Methoden das gleiche, nur dass Methoden an Klassen, Structs und Enums gerichtet sind?


    Würde ich auch so ungefähr sagen.

    TheFuriousLion schrieb:


    Und was genau sind Types? Sind das Klassen, oder Klassen zusammen mit Doubles, Ints, Strangs, etc?


    Types sind alle möglichen Datentypen usw. zusammengefasst. Types Ref.

    TheFuriousLion schrieb:

    Eine typische Klassenmethode wird in Swift als Type Method bezeichnet, richtig?​


    ja, das ist richtig

    ​Instance methods, as described above, are methods that are called on an instance of a particular type. You can also define methods that are called on the type itself. These kinds of methods are called type methods.
    Quelle Type Methods

    TheFuriousLion schrieb:

    Ist Swift weniger objektorientiert, da Strings, Arrays und Dictionarys streng genommen keine Objekte im Sinne einer Instanz mehr sind?


    Eigentlich gibt es in Swift nur noch Objekte.
  • manoh schrieb:

    Eigentlich gibt es in Swift nur noch Objekte.
    In Objective-C waren die Primitive Types ja von C. In Swift sind es dann Klassen oder Structures?


    macmoonshine schrieb:

    Wie misst Du Objekt-Orientierung? Wieso sind Strings, Arrays und Dictionarys keine Objekte? Was meinst Du mit im Sinne einer Instanz?
    Als Objekte werden doch Instanzen einer Klasse bezeichnet, soviel ich weiß, oder? In Swift sind Array und Dictionary als Structures implementiert, während NSArray und NSDictionary als Klassen implementiert sind. Oder werden in Swift auch Instanzen von Structures und Enumerations als Objekte bezeichnet?


    macmoonshine schrieb:

    Alle finden Swift sooo toll, aber keiner weiß warum eigentlich.
    Es sind die Kleinigkeiten, weshalb ich Swift toll finde. Beispielsweise die Property Observers willSet und didSet, die Ranges mit 0...3 und 0..3, oder auch, dass Switch-Case nun nicht mehr auf Zahlen beschränkt ist, nur um ein paar Kleinigkeiten zu nennen.

    Ehrlich gesagt verstehe ich es nicht, warum sich so viele, speziell hier im Formen, gegen Swift aussprechen. Ja, es ist eine neue Sprache, die man lernen muss. Aber am Lernen kann's ja nicht liegen, denn das ist ja schon fast die Hauptaufgabe eines Programmierers, da sich ständig etwas ändert oder etwas neues hinzukommt. Wenn man also immer am neuesten Stand der Dinge sein will, muss man halt Lernen, wie beispielsweise eine neue Programmiersprache. Oder liegt es daran, dass nun wahrscheinlich viele neue Programmierer auf die Apple-Platform kommen werden? Aber ganz ehrlich, Schrottapps gibt es auch jetzt schon zur Genüge, ob da die ein oder andere App dazukommt, ist im Grunde auch schon egal.
  • TheFuriousLion schrieb:

    Ehrlich gesagt verstehe ich es nicht, warum sich so viele, speziell hier im Formen, gegen Swift aussprechen.

    Tun das hier so viele? Ich habe eher den Eindruck, dass hier Swift auch mal nüchtern betrachtet und nicht gleich als den heiligen Gral abgefeiert wird, nur weil Apple sagt, wir haben den heiligen Gral erfunden. Swift ist eine weitere Programmiersprache mit vor und Nachteilen.
  • Michael schrieb:

    TheFuriousLion schrieb:

    Ehrlich gesagt verstehe ich es nicht, warum sich so viele, speziell hier im Formen, gegen Swift aussprechen.

    Tun das hier so viele? Ich habe eher den Eindruck, dass hier Swift auch mal nüchtern betrachtet und nicht gleich als den heiligen Gral abgefeiert wird, nur weil Apple sagt, wir haben den heiligen Gral erfunden. Swift ist eine weitere Programmiersprache mit vor und Nachteilen.

    Ich sehe aktuell noch keine Vorteile bei Swift, welche ich bei Objective-C nicht habe bzw. benötige.Warum sollte ich Swift also verwenden? Nur weil Swift neu und hip ist? Wohl eher nicht.

    Wenn ich eine bestehende iOS App in Objective-C 1:1 mit Swift nachbaue, dann glaube ich auch nicht, dass die App dadurch schneller und effektiver läuft als die bestehende App in Objective-C.

    Ich sehe aktuell nur das Problem, dass man in Zukunft als Freelancer für OS X und iOS Swift anbieten muss, damit man auch Apps updaten kann, welche mit Swift entwickelt wurden. Da warte ich aber erst mal ab, ob bzw. wann Swift als Anforderung bei den Ausschreibungen auftaucht.
  • Das mag schon sein, man darf aber nicht vergessen, dass Swift erst ein paar Tage alt ist. Hier wird sich noch einiges tun und irgendwann wird es so kommen, dass sich Apple auf kurz oder lang von Objective-C trennen wird, denn Apple hat sicher besseres zu tun, als Swift so als Hobby nebenbei zu entwickeln.

    Ich war sowieso erst beim Lernen von Objective-C, von daher ist es für mich eher von Vorteil, wenn ich ab jetzt Swift lerne, da Swift mit großer Wahrscheinlichkeit die Zukunft sein wird.
  • Ich finde Swift nicht schlecht. Mir geht nur dieser Hype auf die Nerven. Da verkauft Apple mit falschen Versprechen irgendwelche alten Konzepte und gibt sie als modern aus. Außerdem höre ich überall, wie einfach doch Swift sei. Wenn ich mir so manches Konstrukt ansehe, kommen mir da arge Zweifel.

    TheFuriousLion schrieb:

    Beispielsweise die Property Observers willSet und didSet

    Ach, endlich hat Apple KVO bzw. das Überschreiben von Methoden erfunden!

    TheFuriousLion schrieb:

    die Ranges mit 0...3 und 0..3

    Wo ist denn da der Vorteil gegenüber einer klassischen For-Schleife?

    TheFuriousLion schrieb:

    dass Switch-Case nun nicht mehr auf Zahlen beschränkt ist

    Das ist in meinen Augen ein krasser Rückschritt, der ahnungslose Anfänger zu Switch-Stinkern verleitet, anstatt über objekt-orientierte Lösungen nachzudenken. <ironie>Ach, das geht ja gar nicht. Swift ist ja objekt-orientiert, also ist jedes Swift-Programm automatisch auch objekt-orientiert.</ironie>

    Wie gesagt finde ich Swift nicht schlecht. Vielleicht erweist es sich in der Praxis sogar als tauglicher als Objective-C. Aber der Ganze Hype um diese Sprache führt meines Erachtens letztendlich nur zu enttäuschten Neueinsteigern, und der Hauptgrund für die Existenz dieser Sprache ist, dass Apple damit Entwickler verstärkt von Android abwerben will.
    „Meine Komplikation hatte eine Komplikation.“
  • Mir ist nicht ganz klar, inwiefern sich Switch-Case zwischen objektorientierten und nicht-objektorientierten Programmiersprachen unterscheidet, aber ich kann mir nicht vorstellen, dass es schlimm ist, dass ich endlich folgendes machen kann:

    Quellcode

    1. switch name {
    2. case "Max Mustermann":
    3. println("That's me!")
    4. default:
    5. println("That's someone else.")
    6. }
  • macmoonshine meint vermutlich, dass man z.B. schönes dynamisches Binden durch switch ersetzen kann, was schlecht(er) ist, oder?

    Ich habe eine andere Frage: Warum gibt es in Swift eine eigene String Klasse, wenn man eh mit dem alten Framework NSString bekommt? Ich nehme mal an, dass man sowieso die meiste Zeit mit dem Foundation Framework arbeitet.
    Die Emojis im String werden wohl nicht der Grund dazu sein? Oder gibt es da noch Unterschiede, die ich nicht erkenne? Und \(x) funktioniert vermutlich nur bei dem Swift String?
  • Dein Beispiel geht übrigens auch mit einem simplen if; also auch kein Gewinn. ;) Aber selbst bei mehreren case-Anweisungen sehe ich keinen Gewinn. Noch mal zur Klarstellung: Es gibt auch sinnvolle Anwendungen für Switch-Anweisungen. Die sind allerdings sehr selten. Die meisten Switch-Anweisungen, die ich im Code irgendeiner objekt-orientierten Programmiersprache gesehen habe, sind Stinker, z. B.:

    Quellcode

    1. ​switch theProduct.taxType {
    2. case "none":
    3. theTaxRate = 0.0
    4. case "food":
    5. theTaxRate = 0.07
    6. default:
    7. theTaxRate = 0.19;
    8. }

    Solche Switch-Anweisungen ziehen sich dann durch den Code, wie ein Fuchsbandwurm durch den Darm.
    „Meine Komplikation hatte eine Komplikation.“
  • joejohannesjoe schrieb:

    Und \(x) funktioniert vermutlich nur bei dem Swift String?
    Nein, sollte auch mit NSString funktionieren.

    macmoonshine schrieb:

    Dein Beispiel geht übrigens auch mit einem simplen if; also auch kein Gewinn.
    Klar, aber bei solchen Unterscheidungen finde ich Switch-Case schöner und übersichtlicher, speziell dann, wenn es viele unterschiedliche Fälle gibt.

    Wäre das für dich eine sinnvolle Verwendung?

    Quellcode

    1. switch compass.direction {
    2. case .North:
    3. doSomethingNorth()
    4. case .South:
    5. doSomethingSouth()
    6. default:
    7. doSomethingOther()
    8. }


    macmoonshine schrieb:

    Solche Switch-Anweisungen ziehen sich dann durch den Code, wie ein Fuchsbandwurm durch den Darm.
    Was passt nicht bei solch einer Verwendung? Wie kann man das besser machen?
  • TheFuriousLion schrieb:

    Aber ist nicht genau das Sinn und Zweck von Switch?
    Ja, aber es ist eben eine schlechte Umsetzung. Du hast 5 verschiedene Fälle. Also hast du in deinem Code 17 Switches mit 5 Zweigen herumfliegen. Jetzt kommt ein sechster Fall hinzu. Das hat etwas österliches: Du musst jetzt die ganzen Eier suchen.

    Modellierst du das mit Klassen, machst du eine sechste Subklasse und modellierst dort durch Überschreiben von Methoden deinen sechsten Fall.
    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"?