Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Richtig. Genau das habe ich gemeint mit "wenn nicht jedes Property für die Serialisierung explizit ausgewählt wird" oder anderst formuliert mit dem "[Serializable]" Attribute versehen.Zitat
Hä? Wenn jeder Typ ein Interface für die Serialisierung implementiert, ist nur dieser Typ für seine Serialisierung zuständig und niemand sonst. Klar, wenn ich den Code in diesem Typ verbocke, habe ich Pech. Ich *kann* aber kompatibel programmieren. Aufwärts und abwärts! Das kannst Du nicht, wenn Du einfach stur alle Properties durch iterierst.
Das ist eben der Vorteil von einem dynamic object. Ob existent oder nicht, neu oder nicht, total egal. Das Objekt bzw. die Klasse wird per Laufzeit erstellt. (Ohne Fehler und Exceptions)Zitat
Klar, aber nur, wenn Du Properties niemals änderst, hinzufügst oder entfernst.
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Du weißt schon, dass Serialisierung auch anders geht als über Attribute? Davon mal abgesehen obliegt es dann eben dem Programmierer dieser Klasse, dass sie richtig serialisiert. Diesen Luxus hast Du bei dynamic objects nicht, wo die Serialisierung extern erledigt und jede dusselige Property genommen wird. Dass die Kompatibilität über einfache [Serializable]-Attribute ebenfalls nicht kompatibel ist, macht die Sache ja nicht besser. Es gibt genug Serialisierungs-Varianten, die eben kompatibel sind zu bisherigen und zukünftigen Dateien.Richtig. Genau das habe ich gemeint mit "wenn nicht jedes Property für die Serialisierung explizit ausgewählt wird" oder anderst formuliert mit dem "[Serializable]" Attribute versehen.
Nein, in diesem Fall ist dies offensichtlich ein Nachteil, weil die Serialisierung damit nicht mehr kompatibel zu bisherigen oder zukünftigen Dateien ist. Ich dachte das hätte ich nun schon dreimal erklärt.Das ist eben der Vorteil von einem dynamic object.
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
Das ist eben der Vorteil von einem dynamic object. Ob existent oder nicht, neu oder nicht, total egal. Das Objekt bzw. die Klasse wird per Laufzeit erstellt. (Ohne Fehler und Exceptions)Zitat
Klar, aber nur, wenn Du Properties niemals änderst, hinzufügst oder entfernst.
Ob das ganze dann von deiner Software verwendet werden kann oder nicht, hängt von der weiteren Implementierung ab.
Ich will nicht um den heißen Brei reden. Ich gebe dir recht, jedoch will ich auf das überhaupt nicht hinausZitat
Du weißt schon, dass Serialisierung auch anders geht als über Attribute? Davon mal abgesehen obliegt es dann eben dem Programmierer dieser Klasse, dass sie richtig serialisiert. Diesen Luxus hast Du bei dynamic objects nicht, wo die Serialisierung extern erledigt und jede dusselige Property genommen wird. Dass die Kompatibilität über einfache [Serializable]-Attribute ebenfalls nicht kompatibel ist, macht die Sache ja nicht besser. Es gibt genug Serialisierungs-Varianten, die eben kompatibel sind zu bisherigen und zukünftigen Dateien.
Es geht ja nicht darum, dass wenn man es falsch macht, auch wieder Mist herauskommt. Das gilt nämlich generell bei Programmierung. Es geht darum, dass es bei dynamic objects keinen vernünftigen Weg gibt solche Kompatibilität überhaupt zu gewährleisten. Das Gegenteil ist bei Serialisierung der Fall. Man kann sie gewährleisten.
Zitat
Ich kann mich BlueCobold nur anschließen.
Der Vorteil, wenn man die Serialisierung "selbst" schreibt, ist, dass man auf ein definiertes Format zurückgreifen kann. Auch wenn in der internen Repräsentation der Daten sich etwas ändert (long statt int, eine eigene Enumeration statt String, eine Umbenennung), kann man immernoch alte Formate laden und ggf. die Daten immernoch in diese speichern. Fügt man eine Versionsnummer hinzu, kann man ältere Formate sehr leicht erkennen und darauf eingehen, da der Code zum Einlesen bereits vorhanden war.
Die "test" Variable ist vom Typ String, kann deshalb auch nicht erweitert werden. Was du suchst ist ein ExpandoObject. Versuch es damit noch einmal, dann gehts.Zitat
Das stimmt so pauschal nicht, siehe Screenshot im Anhang. Meinst du vielleicht dynamic Referenzen auf eine bestimmte Klasse die die nötige Magic mitbringt?
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Deswegen ist die ja auch Mist Zumindest kenne ich keinen produktiven Einsatz dieser Serialisierung bei uns. Eben weil Änderungen immer mal vorkommen und man damit rechnen muss.Wird die Standard Serialisierung von .net verwendet, ist auch keine Kompatibilität gewährleistet.
Das ist aber Unfug. Die von .Net ist eine der vielen Möglichkeiten. Spricht man von Serialisierung, meint man das generelle Verfahren logische Programmdaten in einen Bytestrom zu verwandeln, sodass diese persistier- oder verschickbar sind. Man meint damit nicht den ganz speziellen Mechanismus eines speziellen Frameworks.Und bei Serialisierung verstehe ich die Standard von .net angebotene Serialisierung.
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
Werbeanzeige