Struct error

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

  • Den Code gibt es bereits, hatte ich schon geschrieben. Findest du bei SO etwa 12937129837 Mal. Benutzt bloß keiner auf längere Sicht, weil generische Initialisierung keinen Vorteil bietet. Ist halt son Sekretärinnending, was dann doch wieder unbrauchbar wird.

    Wieso das allerdings unsicher ist, erschließt ich mir nicht.
    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"?

  • Gesehen habe ich äquivalenten Code bisher nirgendwo - aber das Suchen macht wohl noch weniger Spaß als das Schreiben, sonst hätte die Antwort aus Copy & Paste bestehen können:
    Spart nicht nur Zeit, sondern ist auch fundierter als unbelegte Behauptungen.
    Ich frage mich nur, ob das noch die "kann Objective-C mindestens genau so gut" oder schon die "braucht man eh nicht"-Phase ist...

  • t-no schrieb:

    Ich frage mich nur, ob das noch die "kann Objective-C mindestens genau so gut" oder schon die "braucht man eh nicht"-Phase ist...

    Das ist die 'dynamisch ist halt was Anderes…' Phase. :P
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • t-no schrieb:

    Gesehen habe ich äquivalenten Code bisher nirgendwo - aber das Suchen macht wohl noch weniger Spaß als das Schreiben, sonst hätte die Antwort aus Copy & Paste bestehen können:
    Spart nicht nur Zeit, sondern ist auch fundierter als unbelegte Behauptungen.
    Ich frage mich nur, ob das noch die "kann Objective-C mindestens genau so gut" oder schon die "braucht man eh nicht"-Phase ist...

    Ich helfe dir ein bisschen auf die Sprünge:
    stackoverflow.com/questions/19…ay-of-objects-objective-c
    stackoverflow.com/questions/25…ined-class-in-objective-c
    stackoverflow.com/questions/10…or-nsobject-based-classes
    secretlab.com.au/blog/2012/07/…-load-objective-c-objects
    objective-cloud.com

    Es ist die einfach: "Ich habe Ahnung, wovon ich rede"-Phase. Solltest du vielleicht mal eintreten.
    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:

    Es ist die einfach: "Ich habe Ahnung, wovon ich rede"-Phase. Solltest du vielleicht mal eintreten.

    Scheint ja ein ganz lustiger Zustand zu sein, trotzdem glaube ich nicht, dass ich persönlich Spaß daran hätte - aber wer Freude an langatmigen Diskussionen hat, findet so vielleicht sein Glück.

    "Initialisieren mittels JSON-Strings" war von mir eigentlich eher als Scherz gemeint - um was anderes scheint es in den verlinkten Beiträgen ja leider nicht zu gehen (da aber wohl immerhin mit Daten, die von sich aus in JSON-Form vorliegen).
    Solange nicht einmal die vermeintlich einfache Aufgabe mit dem äquivalenten Code gelöst wird, halte ich Debatten eh für unsinnig (mit Swift braucht man übrigens keine zwei Minuten).

  • Vor kurzem ist die "Herausforderung" übrigens etwas weniger nervig geworden: Für Objective-C gibt es jetzt "nonnull" (ob es für normale Variablen auch wieder eine stylische Variation mit Unterstrich-Prefix gibt, habe ich noch nicht gesehen.
    Mal nachgezählt:
    "?" -> 1 Buchstabe
    "nonnull" -> 7
    (ohne weiteren Kommentar)

    Falls die Swift-Hasser diese Neuerung jetzt auch verteufeln, kann ich sogar mal ein bisschen Verständnis für sie aufbringen - in dem Fall hätte Swift ja tatsächlich dafür gesorgt, dass Objective-C "leidet" (ansonsten kann ich mich generell nur über das Geschimpfe wundern - es ist ja nicht so, dass Objective-C absolut schlechter wird, nur weil Apple eine neue Sprache entwickelt hat).

  • t-no schrieb:

    Für Objective-C gibt es jetzt "nonnull"

    Boah, kann mal jemand diese verf***ten Compilerbauer von meiner Programmiersprache fern halten?
    Dieses 'nonnull' (welches syntaktisch korrekt eigentlich 'notNil' heißen müsste…) ist doch nur irgend eine Krücke, die Nullpointer Exceptions in den Methoden verhindert. Ergo ein Schmiss, der nur für Swift eingeführt wurde, denn: in Objective-C gibt es keine Nullpointer Exception.

    Dinge wie diese sind es, die mir Swift immer weniger sympathisch werden lassen.
    Es wirkt fast so, als hätte Apple sein gesamtes Objective-C Team rausgeworfen und versucht jetzt mit studierten Compilerbauern alles den Bach runter zu wirtschaften.

    Das ist doch echt zum k***en. Jetzt wird also hinten rum das Framework so verwurschtet, dass es mit Swift zusammenarbeiten kann, anstatt Swift so zu gestalten, dass es mit dem Framework zusammenarbeiten kann.

    They're doin' it wrong!
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Marco Feltmann schrieb:

    t-no schrieb:

    Für Objective-C gibt es jetzt "nonnull"

    Boah, kann mal jemand diese verf***ten Compilerbauer von meiner Programmiersprache fern halten?
    Dieses 'nonnull' (welches syntaktisch korrekt eigentlich 'notNil' heißen müsste…) ist doch nur irgend eine Krücke, die Nullpointer Exceptions in den Methoden verhindert. Ergo ein Schmiss, der nur für Swift eingeführt wurde, denn: in Objective-C gibt es keine Nullpointer Exception.

    Dinge wie diese sind es, die mir Swift immer weniger sympathisch werden lassen.
    Es wirkt fast so, als hätte Apple sein gesamtes Objective-C Team rausgeworfen und versucht jetzt mit studierten Compilerbauern alles den Bach runter zu wirtschaften.

    Das ist doch echt zum k***en. Jetzt wird also hinten rum das Framework so verwurschtet, dass es mit Swift zusammenarbeiten kann, anstatt Swift so zu gestalten, dass es mit dem Framework zusammenarbeiten kann.

    They're doin' it wrong!


    naja, zum glück muss man es nicht verwenden.

    es macht aber meiner meinung nach auch nicht viel sinn.
    denn normalerweise sieht man ja doch schon aus dem methodennamen was nil sein kann und was nicht (und genaueres steht eh in der doku).
    dem programmierer der methode hilft es auch nicht weiter weil er ja weiterhin überprüfen muss ob nil (oder ein objekt der falschen klasse) übergeben wurde.

  • t-no schrieb:

    (ansonsten kann ich mich generell nur über das Geschimpfe wundern - es ist ja nicht so, dass Objective-C absolut schlechter wird, nur weil Apple eine neue Sprache entwickelt hat).

    Doch, genau das ist der Fall.
    Seit es Swift gibt (und die Entwickler auf das Gemecker verkappter Java-Anhänger hören) findet man an allen Ecken und Enden Ungereimtheiten im Framework, die es vorher nicht gab.
    ARC zum Beispiel. Im Prinzip ist ARC ja schon was Tolles, nimmt es einem doch den Kram ab, den einem der Static Analyzer an Verbesserungswünschen vor den Kopf geknallt hat.
    Nur fehlt jetzt Kontrolle. Konnte man damals™ noch feststellen, dass der Static Analyzer das korrekt anmeckert, weil das eigentlich ganz anders gemeint war, behebt ARC das Problem jetzt – im schlimmsten Fall falsch.

    Naja, der Wunsch der Gesellschaft spiegelt sich halt auch in den Programmiersprachen wider:
    Alles ein bisschen einfacher, dafür geben wir gern Kontrolle an Andere ab und verlassen uns blauäugig darauf, dass die schon die richtigen Entscheidungen treffen werden.

    Ach, ich reg' mich schon wieder völlig unnütz auf.
    Zum Glück sind die Structs immer noch Structs und die Enums immer noch Enums. Wenn ich jetzt noch wie in Swift Datenstrukturen mit Methoden anreichern könnte, dann gäbe es ja überhaupt keine Existenzberechtigungen mehr für die Datenstrukturen.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • gritsch schrieb:

    dem programmierer der methode hilft es auch nicht weiter weil er ja weiterhin überprüfen muss ob nil (oder ein objekt der falschen klasse) übergeben wurde.

    Das ist nur halb richtig. Im Fall der 'nonnull' Annotation prüft nämlich der Compiler, ob das zur Compilezeit übergebene Objekt nil ist und verweigert dann den Compiliervorgang mit einem Fehler.
    In Java, C# und Konsorten ist dies ein sehr beliebtes Hilfsmittel, welches gefühlt 90% aller potentiellen NullPointerExceptions verhindert.
    Nur leider verhindert es in genannten Sprachen NullPointerException zur Laufzeit nicht und ist für eine Programmiersprache, die stumpf keine NullPointerExceptions kennt, absolut fehl am Platz.
    Objective-C kann es jetzt nur, weil der Clang Compiler das auch kann…
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Marco Feltmann schrieb:

    Das ist nur halb richtig. Im Fall der 'nonnull' Annotation prüft nämlich der Compiler, ob das zur Compilezeit übergebene Objekt nil ist und verweigert dann den Compiliervorgang mit einem Fehler.


    nur das kann er gar nicht wissen zum compilezeitpunkt.

    Quellcode

    1. id tmpObject = [myArray firstObject]; // ist das nun nil oder nicht ;-)
    3. [SomeClassOrObject someMethodWithNonnullParameter:tmpObject]; // is this ok or not? ;-)

  • t-no schrieb:

    Mal nachgezählt:
    "?" -> 1 Buchstabe
    "nonnull" -> 7

    Wenn du die Qualität einer Programmiersprache anhand der Länge ihrer Bezeichner vergleichst, solltest du dich bei C sehr wohl fühlen. ;) +scnr+

    Im Ernst: Ob das nonnull in Objective-C jetzt nützlich oder eher hinderlich ist, ist meines Erachtens Geschmackssache. Ich finde das explizite Schlüsselwort aber wesentlich aussagekräftiger als diese kryptischen ?- und !-Suffixe.
    „Meine Komplikation hatte eine Komplikation.“

  • gritsch schrieb:

    Marco Feltmann schrieb:

    Das ist nur halb richtig. Im Fall der 'nonnull' Annotation prüft nämlich der Compiler, ob das zur Compilezeit übergebene Objekt nil ist und verweigert dann den Compiliervorgang mit einem Fehler.


    nur das kann er gar nicht wissen zum compilezeitpunkt.

    Quellcode

    1. id tmpObject = [myArray firstObject]; // ist das nun nil oder nicht ;-)
    3. [SomeClassOrObject someMethodWithNonnullParameter:tmpObject]; // is this ok or not? ;-)

    In vielen Fällen kann er das.
    Beispielsweise wird er Dir in diesem Fall die Fehlermeldung um die Ohren hauen, dass 'myArray' unbekannt ist.
    Sobald myArray instanziiert wird, kann er auch erkennen, ob es ein erstes Objekt gibt oder nicht.

    Er kann aber natürlich nicht erkennen, ob Du Dir an anderer Stelle beispielsweise mitten drin myArray durch ein leeres Array ersetzt hast.
    Immerhin kannst Du aber gemäß Definition kein nil Objekt als erstes Objekt des Arrays anlegen. ;)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • macmoonshine schrieb:

    Ich finde das explizite Schlüsselwort aber wesentlich aussagekräftiger als diese kryptischen ?- und !-Suffixe

    Imho auch Ansichtssache - auf jeden Fall integriert sich das Fragezeichen besser (auf Bandwurm-Typen in der Art "static const * const volatile char" kann ich gern verzichten) und ist in vielen anderen Sprachen schon etabliert (wie leider auch "_" - irgendwie habe ich eine tief verwurzelte Abneigung gegen Unterstriche... ;)

  • Marco Feltmann schrieb:

    gritsch schrieb:

    Marco Feltmann schrieb:

    Das ist nur halb richtig. Im Fall der 'nonnull' Annotation prüft nämlich der Compiler, ob das zur Compilezeit übergebene Objekt nil ist und verweigert dann den Compiliervorgang mit einem Fehler.


    nur das kann er gar nicht wissen zum compilezeitpunkt.

    Quellcode

    1. id tmpObject = [myArray firstObject]; // ist das nun nil oder nicht ;-)
    3. [SomeClassOrObject someMethodWithNonnullParameter:tmpObject]; // is this ok or not? ;-)

    In vielen Fällen kann er das.
    Beispielsweise wird er Dir in diesem Fall die Fehlermeldung um die Ohren hauen, dass 'myArray' unbekannt ist.
    Sobald myArray instanziiert wird, kann er auch erkennen, ob es ein erstes Objekt gibt oder nicht.

    Er kann aber natürlich nicht erkennen, ob Du Dir an anderer Stelle beispielsweise mitten drin myArray durch ein leeres Array ersetzt hast.
    Immerhin kannst Du aber gemäß Definition kein nil Objekt als erstes Objekt des Arrays anlegen. ;)


    jetzt komm, klar ist myArray irgend ein array das irgendwoher kommt (nicht direkt davor erstellt sonst würde es der compiler ja wirklich kennen).

  • macmoonshine schrieb:

    gritsch schrieb:

    nur das kann er gar nicht wissen zum compilezeitpunkt.

    Der Compiler sollte hier einen Fehler ausgeben, da der Rückgabewert in der Methodendeklaration von firstObject nicht als nonnull gekennzeichnet ist.

    Da sieht man mal, wie objektorientiert ich denke… DAS wäre natürlich die korrekte Compilerbaudenkweise.
    Fragen ob es nil ist vs. sagen lassen, wenn es nicht nil ist…
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • gritsch schrieb:

    jetzt komm, klar ist myArray irgend ein array das irgendwoher kommt (nicht direkt davor erstellt sonst würde es der compiler ja wirklich kennen).

    Das sind dann die ca. 10%, die auch bei Java, C# und Konsorten in die Grütze gehen. Nämlich immer dann, wenn Dir zur Laufzeit ein Objekt abhanden kommt.
    Die Sicherheit, die 'nonnull' vortäuscht, bietet es halt nicht.
    Das sorgt dann dafür, dass man sich darauf verlässt, dass das Objekt 'nonnull' ist und plötzlich kracht es, weil es eben nicht 'nonnull' war. Egal was vorher verhandelt wurde.

    Ich weiß ehrlich gesagt auch nicht, ob da nur kompiliert oder auch ein Static Analyzer involviert ist.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • t-no schrieb:

    macmoonshine schrieb:

    Ich finde das explizite Schlüsselwort aber wesentlich aussagekräftiger als diese kryptischen ?- und !-Suffixe

    Imho auch Ansichtssache - auf jeden Fall integriert sich das Fragezeichen besser (auf Bandwurm-Typen in der Art "static const * const volatile char" kann ich gern verzichten) und ist in vielen anderen Sprachen schon etabliert (wie leider auch "_" - irgendwie habe ich eine tief verwurzelte Abneigung gegen Unterstriche... ;)


    Marco Feltmann schrieb:

    gritsch schrieb:

    jetzt komm, klar ist myArray irgend ein array das irgendwoher kommt (nicht direkt davor erstellt sonst würde es der compiler ja wirklich kennen).

    Das sind dann die ca. 10%, die auch bei Java, C# und Konsorten in die Grütze gehen. Nämlich immer dann, wenn Dir zur Laufzeit ein Objekt abhanden kommt.
    Die Sicherheit, die 'nonnull' vortäuscht, bietet es halt nicht.
    Das sorgt dann dafür, dass man sich darauf verlässt, dass das Objekt 'nonnull' ist und plötzlich kracht es, weil es eben nicht 'nonnull' war. Egal was vorher verhandelt wurde.


    hä?

    dann eben so:

    Quellcode

    1. ​NSArray *myArray = [[NSUserdefaults ...] arrayForKey:@"meinkey"]


    in 90% der fälle weis der compiler bei mir nicht ob das array gefüllt ist oder nicht (denn der inhalt kommt aus einer datenbank, wird zur laufzeit generiert oder eventuell auch aus userdefaults und konsorten).

  • Exakt. Und in 10% der Fälle weiß der Compiler das bei Java, C#, Swift, … auch nicht.
    Bei Java und C# geht der Compiler davon aus, dass es das Objekt da gibt, da dort nie 'null' zurückgegeben werden darf.
    [Das Array kann kein Element 'null' sein und soweit ich weiß gibt es da firstObject nicht mal. Würde man also mit objectAtIndex(0) gleich setzen und eher eine OutOfBoundsException kassieren denn ein 'null' Objekt zurück bekommen. Zumal sich ein Java Array aus Gründen nicht mal eben um eine Kategorie erweitern lässt…]

    In Java und C# gibt es an allen Ecken Try-Catch-Konstrukte, die alle möglichen Exceptions (darunter NullPointerException) abfangen sollen. Diese spart man sich oftmals, wenn man einer Methode sagen kann, dass ein Element nie null sein darf.
    Zur Laufzeit kann aber alles mögliche passieren. Datei fehlt und der Handle wird genullt. Memory voll und ein paar Instanzvariablen werden genullt. Das per Definition mutable Array wird irgendwo anders geleert und dann erst wird mit der Methode gearbeitet.

    Genau deshalb ist es doch in Objective-C so ein unsinniger Unsinn. ;)
    In Objective-C ist alles ein Objekt, auch nil.
    Überall sonst ist null ein kleiner aussätziger Rebell, der einfach passiert und auf jeden Fall ausgesperrt werden muss.

    Und genau deshalb empfinde ich Swift als Beleidigung.
    Jetzt darf ich also in Zukunft Rückschlüsse über die Klasse eines Objektes ziehen, wenn ich wissen will, ob das Objekt etwas kann – anstatt einfach das Objekt selbst zu fragen. Herzlichen Dank Apple.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P