Struct error

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

  • Marco Feltmann schrieb:

    Nur damit ich das richtig verstehe:
    es wird sich darüber beschwert, dass man Properties nur mit Tipperei mit Standardwerten belegen kann, welche von den vom Compiler vorbelegten Standardwerten abweicht.

    Dazu fällt mir dann aber auch nix mehr ein…


    ich denke er meint dass man in swift User(name: "Marco" age:99) etc schreiben kann ohne dass es dafür einen cunstructor geben muss (keine ahnung ob das so ist in swift...)

  • Marco Feltmann schrieb:

    Nur damit ich das richtig verstehe:
    es wird sich darüber beschwert, dass man Properties nur mit Tipperei mit Standardwerten belegen kann, welche von den vom Compiler vorbelegten Standardwerten abweicht.

    Dazu fällt mir dann aber auch nix mehr ein…
    Er weist ja darauf hin, dass es auch ungesund sei!
    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"?

  • gritsch schrieb:

    Marco Feltmann schrieb:

    Nur damit ich das richtig verstehe:
    es wird sich darüber beschwert, dass man Properties nur mit Tipperei mit Standardwerten belegen kann, welche von den vom Compiler vorbelegten Standardwerten abweicht.

    Dazu fällt mir dann aber auch nix mehr ein…


    ich denke er meint dass man in swift User(name: "Marco" age:99) etc schreiben kann ohne dass es dafür einen cunstructor geben muss (keine ahnung ob das so ist in swift...)
    Ein new: mit einem Dictionary, das als Argument übergeben wird, kann man in Objective-C für alle Klassen generisch formulieren. Ist für einen Swifter vielleicht nicht so einsichtig.

    Mit offener Parameterliste ginge das sogar mit C-Typen.

    Stellt sich nur die Frage, warum das keiner macht?
    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"?

  • gritsch schrieb:

    Marco Feltmann schrieb:

    Nur damit ich das richtig verstehe:
    es wird sich darüber beschwert, dass man Properties nur mit Tipperei mit Standardwerten belegen kann, welche von den vom Compiler vorbelegten Standardwerten abweicht.

    Dazu fällt mir dann aber auch nix mehr ein…


    ich denke er meint dass man in swift User(name: "Marco" age:99) etc schreiben kann ohne dass es dafür einen cunstructor geben muss (keine ahnung ob das so ist in swift...)

    jo, statt

    Quellcode

    1. let me : User = User(name: "Marco", age:99)


    könnte man allerdings

    Quellcode

    1. User *me = [User new];
    2. me.name = @"Marco";
    3. me.age = 99;


    schreiben. Das ist allerdings ungesund.
    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"?

  • Wow da habe ich ja eine Diskussion in Gang gebracht :)

    Thallius schrieb:

    Bitte poste Deine Fragen doch im dafür vorgesehen Forum "Swift" und nicht unter Tipps und Tricks.


    Oh sorry das werde ich in Zukunft beachten !

    schumi schrieb:

    Nein, es hat nichts mit Xcode zu tun. So wie du die For-Schleife programmiert hast, wird der Fehler in jeder Programmiersprache passieren. Ich sag nur lokale Variablen.


    Ja das ist mir kurze Zeit später auch aufgefallen. Habe es dann umgehend gefixt.

    t-no schrieb:

    Ja: Warum Daten in einen Array packen, nur um sie danach in eine andere Struktur zu kopieren?
    "DataArrayIn" ist eh ein schlechter Name, weglassen, und gleich Recipe nehmen.


    Ich habe ja mehrere Datensätze in der MySQL Datenbank. Deswegen komm ich doch gar nicht drum rum oder?

    little_pixel schrieb:

    Da wir hier bei Tips und Tricks sind kann ich Dir empfehlen ein NSDictionary statt nem Struct zu nehmen.

    Ist doch viel cooler…


    NSDictionarys muss ich mir noch genauer anschauen. Das werde ich sicher noch verwenden.

    Marco Feltmann schrieb:

    Dein Fehler liegt in den Grundlagen.
    Quellcode
    var count = 0
    for element in workdata {
    var newData = mydata(id: element[0].string, name: element[1].string, description: element[2].string) count++
    }
    self.mydata = [newData]

    So sieht das nach Blödsinn aus.
    Du musst schon jedes einzelne Element irgendwo speichern.


    Ja da hast du recht. Du weißt ja ich lerne noch fleißig und aller Anfang ist schwer :D.
    Ich hatte gedacht, das man jedes Element direkt verwenden kann, ohne es zwischen zu speichern.

    Ich danke euch für die vielen Antworten und Ratschläge !

    Viele Grüße David

  • Nein, es ist eben doch mehr boiler-plate in obj-c nötig. Wenn die properties alle read-only sind, braucht man zwingend einen eigenen Initialisierer. Ausserdem muss man mit großer Wahrscheinlichkeit copyWithZone überschreiben (zumindest wenn die properties readwrite sein sollen, ausserdem muss man sich dann noch um die korrekte copy-Semantik kümmern, was in Swift durch die Sprache erledigt wird) - eine fehleranfällige und lästige Sache...

  • Markus Müller schrieb:

    Nein, es ist eben doch mehr boiler-plate in obj-c nötig. Wenn die properties alle read-only sind, braucht man zwingend einen eigenen Initialisierer. Ausserdem muss man mit großer Wahrscheinlichkeit copyWithZone überschreiben (zumindest wenn die properties readwrite sein sollen, ausserdem muss man sich dann noch um die korrekte copy-Semantik kümmern, was in Swift durch die Sprache erledigt wird) - eine fehleranfällige und lästige Sache...


    die struct ist aber auch in swift r/w also warum etwas voraussetzen was in der anderen sprache nicht vorausgesetzt wird?
    wozu copyWithZone? hätt ich noch nie benötigt...

  • Markus Müller schrieb:

    Nein, es ist eben doch mehr boiler-plate in obj-c nötig. Wenn die properties alle read-only sind, braucht man zwingend einen eigenen Initialisierer.

    Das stimmt nicht. Ein generischer Initialisierer kann selbstverständlich auch ro-Propertys setzen. Macht bloß immer noch keiner.

    Markus Müller schrieb:

    Ausserdem muss man mit großer Wahrscheinlichkeit copyWithZone überschreiben (zumindest wenn die properties readwrite sein sollen, ausserdem muss man sich dann noch um die korrekte copy-Semantik kümmern, was in Swift durch die Sprache erledigt wird) - eine fehleranfällige und lästige Sache...

    Außerdem muss man sich so gut wie nie im -copyWithZone: kümmern, weil Kopien von Custom-Objekten in Objective-C sehr selten sind.
    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"?

  • Amin Negm-Awad schrieb:

    Markus Müller schrieb:

    Nein, es ist eben doch mehr boiler-plate in obj-c nötig. Wenn die properties alle read-only sind, braucht man zwingend einen eigenen Initialisierer.

    Das stimmt nicht. Ein generischer Initialisierer kann selbstverständlich auch ro-Propertys setzen. Macht bloß immer noch keiner.

    Den generischen Initialisierer musst Du aber dennoch schreiben (und warten...)

    Amin Negm-Awad schrieb:


    Markus Müller schrieb:

    Ausserdem muss man mit großer Wahrscheinlichkeit copyWithZone überschreiben (zumindest wenn die properties readwrite sein sollen, ausserdem muss man sich dann noch um die korrekte copy-Semantik kümmern, was in Swift durch die Sprache erledigt wird) - eine fehleranfällige und lästige Sache...

    Außerdem muss man sich so gut wie nie im -copyWithZone: kümmern, weil Kopien von Custom-Objekten in Objective-C sehr selten sind.

    Es ging ja darum, ein Swift-Equivalent in obj-c umzusetzen. Und da Swift-structs Wertsemantik haben, brauchst Du -copyWithZone wenn die Klasse mutable ist.

    Happy flaming!

  • dann schreib ich mir aber gleiche inen vernünftigen initializer. also initWithDictionary. der überprüft dann ob die werte darin korrekt sind und setzt diese gegebenenfalls.

    wozu braucht man copyWithZone wenn die klasse mutable ist??? das braucht man doch nur wenn man die klasse bzw dessen objekte auch kopieren will und das will man ja höchst selten (mir noch nie passiert).

  • gritsch schrieb:

    Markus Müller schrieb:

    Nein, es ist eben doch mehr boiler-plate in obj-c nötig. Wenn die properties alle read-only sind, braucht man zwingend einen eigenen Initialisierer. Ausserdem muss man mit großer Wahrscheinlichkeit copyWithZone überschreiben (zumindest wenn die properties readwrite sein sollen, ausserdem muss man sich dann noch um die korrekte copy-Semantik kümmern, was in Swift durch die Sprache erledigt wird) - eine fehleranfällige und lästige Sache...


    die struct ist aber auch in swift r/w also warum etwas voraussetzen was in der anderen sprache nicht vorausgesetzt wird?
    wozu copyWithZone? hätt ich noch nie benötigt...

    Nein, die weiter oben gepostete struct war readonly (alle properties mit let deklariert). Structs werden in Swift immer kopiert, eine eigene copy-Methode muss nicht implementiert werden.

  • Ein generischen Initialisierer muss einmal geschrieben werden vom irgendwem. JSON-to-Object habe ich schon viele gesehen. Nimmt bloß keiner in seinem normalen Code. Irgendeinen Grund wird es dafür sicherlich geben.
    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"?

  • Markus Müller schrieb:

    gritsch schrieb:

    Markus Müller schrieb:

    Nein, es ist eben doch mehr boiler-plate in obj-c nötig. Wenn die properties alle read-only sind, braucht man zwingend einen eigenen Initialisierer. Ausserdem muss man mit großer Wahrscheinlichkeit copyWithZone überschreiben (zumindest wenn die properties readwrite sein sollen, ausserdem muss man sich dann noch um die korrekte copy-Semantik kümmern, was in Swift durch die Sprache erledigt wird) - eine fehleranfällige und lästige Sache...


    die struct ist aber auch in swift r/w also warum etwas voraussetzen was in der anderen sprache nicht vorausgesetzt wird?
    wozu copyWithZone? hätt ich noch nie benötigt...

    Structs werden in Swift immer kopiert, eine eigene copy-Methode muss nicht implementiert werden.


    objekte in obj-c aber nicht und deswegen brauchts auch kein copyWithZone.

  • Markus Müller schrieb:

    Amin Negm-Awad schrieb:

    Markus Müller schrieb:

    Nein, es ist eben doch mehr boiler-plate in obj-c nötig. Wenn die properties alle read-only sind, braucht man zwingend einen eigenen Initialisierer.

    Das stimmt nicht. Ein generischer Initialisierer kann selbstverständlich auch ro-Propertys setzen. Macht bloß immer noch keiner.

    Den generischen Initialisierer musst Du aber dennoch schreiben (und warten...)

    Amin Negm-Awad schrieb:


    Markus Müller schrieb:

    Ausserdem muss man mit großer Wahrscheinlichkeit copyWithZone überschreiben (zumindest wenn die properties readwrite sein sollen, ausserdem muss man sich dann noch um die korrekte copy-Semantik kümmern, was in Swift durch die Sprache erledigt wird) - eine fehleranfällige und lästige Sache...

    Außerdem muss man sich so gut wie nie im -copyWithZone: kümmern, weil Kopien von Custom-Objekten in Objective-C sehr selten sind.

    Es ging ja darum, ein Swift-Equivalent in obj-c umzusetzen. Und da Swift-structs Wertsemantik haben, brauchst Du -copyWithZone wenn die Klasse mutable ist.

    Happy flaming!
    Nein, dann ginge es darum, Swift in Objective-C umzusetzen.
    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"?

  • gritsch schrieb:

    dann schreib ich mir aber gleiche inen vernünftigen initializer. also initWithDictionary. der überprüft dann ob die werte darin korrekt sind und setzt diese gegebenenfalls.

    wozu braucht man copyWithZone wenn die klasse mutable ist??? das braucht man doch nur wenn man die klasse bzw dessen objekte auch kopieren will und das will man ja höchst selten (mir noch nie passiert).

    Ein initWithDictionary ist m.M.n. kein vernünftiger Initialisierer, aber das hatten wir hier ja schon. copyWithZone brauchst Du für mutable Klassen, wenn Du Swifts Wertsemantik haben möchtest. Ist z.B. nützlich, dass Du Wertobjekte rumreichen kannst und Du Dir um Threadsicherheit keine Gedanken machen musst.

  • Wieso ist das nach einer Meinung kein "vernünftiger Initialisierer" und was macht einen Initialisierer überhaupt vernünftig?

    Objekte herumreichen kann ich die auch read-only, ohne mir Gedanken zu machen. Das Problem liegt mehr in der Zusammenführung. Ach, ja, Wertobjekte muss ich auch wieder zusammenführen.
    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"?

  • Amin Negm-Awad schrieb:

    Wieso ist das nach einer Meinung kein "vernünftiger Initialisierer" und was macht einen Initialisierer überhaupt vernünftig?


    Weil man sich dann selber um die Validierung kümmern muss, anstatt es den Compiler machen zu lassen. Ausserdem verschleiert das die Abhängigkeiten der Klasse. ein initWithDicitionary ist m.M.n. schlechter lesbar als ein initWithDependencyA:(DependencyA*) dependencyB:(DependencyB*) usw.

    Amin Negm-Awad schrieb:


    Objekte herumreichen kann ich die auch read-only, ohne mir Gedanken zu machen. Das Problem liegt mehr in der Zusammenführung. Ach, ja, Wertobjekte muss ich auch wieder zusammenführen.


    Mein Hinweis mit copyWithZone bezog sich auf mutable Instanzen, ich zitiere mich selbst:

    Markus Müller schrieb:


    ...brauchst Du -copyWithZone wenn die Klasse mutable ist.

  • Der generische Initialisierer kümmert sich um die Validierung, nicht man selbst. Ein -initWithDictionary:… ist in der Tat schlechter lesbar als ein -initWithA:B:. Es ist nämlich so schlecht lesbar wie ein generisches User( ), welches hier für Swift angepriesen wurde.

    Man lernt also:
    In Objective-C ist so ein generisches Zeugs schlecht lesbar und obwohl es problemlos geht, macht man es nicht.
    In Swift ist so ei generisches Zeugs total supi, weil es Tipparbeit spart.

    Du hattest geschrieben:
    " copyWithZone brauchst Du für mutable Klassen, wenn Du Swifts Wertsemantik haben möchtest. Ist z.B. nützlich, dass Du Wertobjekte rumreichen kannst und Du Dir um Threadsicherheit keine Gedanken machen musst."
    Darauf meine Antwort: Du reichst keine Mutable-Instanzen herum, sondern immutable. Dann brauchst du auch kein Copy.Oder noch anders: Du bietest eine Lösung für ein Problem an, welches in Objective-C gar nicht erst existiert.
    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"?

  • gritsch schrieb:

    dann schreib ich mir aber gleiche inen vernünftigen initializer. also initWithDictionary.

    Das ist doch hoffentlich ein Scherz, oder?
    Ansonsten kann man das auch noch einfacher machen, und gleich alles mit JSON-Strings regeln - dass ist imho sogar noch sinnvoller, da die Daten in der Realität oft so reinkommen.
    Ausser CoreData fällt mir zum Glück gerade keine Cocoa-API ein, die den fehleranfälligen und komplizierten Umweg über Dictionaries geht (und das ist gut so - die "Visual Formatting Language" ist schon schlimm genug).
    Übrigens möchte ich festhalten, dass niemand äquivalenten Objective-C Code zu meinem Beispiel geschrieben hat: Macht halt echt keinen Spaß.