spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

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.

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

Klar, aber nur, wenn Du Properties niemals änderst, hinzufügst oder entfernst.

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)
Ob das ganze dann von deiner Software verwendet werden kann oder nicht, hängt von der weiteren Implementierung ab.

Zitat von »Toemsel«

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.

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 von »Toemsel«

Das ist eben der Vorteil von einem dynamic object.

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.
Zudem ist dynamic hier die total falsche Herangehensweise. Aber auch das haben wir ja schon geklärt.

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.

Was würde denn passieren, wenn man in seiner Klasse ein Attribut "Foo" umbenennt (bspw. "Bar") und daraufhin eine Methode in "Foo" umbenennt? Würde die Methode ersetzt werden, würde es einen Fehler geben oder wäre es gar nicht dazu in der Lage, die ursprünglich verwendete Klasse zu erkennen?
Es wurde ja bereits geschrieben, dass in dem gegebenen Fall ein Dictiobnary<String, String> besser geeignet wäre. (Wenn man will, könnte man dafür auch eine Klasse "FileInfos" o. ä. packen, intern wäre es aber dennoch der gleiche Typ, der verwendet wird.) Da der Typ der Daten bekannt ist, gibt es keinen Grund, ein Sprachkonstrukt zu verwenden, welches einen unbekannten Datentypen suggeriert.

Zitat von »Toemsel«

Zitat

Klar, aber nur, wenn Du Properties niemals änderst, hinzufügst oder entfernst.

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)
Ob das ganze dann von deiner Software verwendet werden kann oder nicht, hängt von der weiteren Implementierung ab.

Das stimmt so pauschal nicht, siehe Screenshot im Anhang. Meinst du vielleicht dynamic Referenzen auf eine bestimmte Klasse die die nötige Magic mitbringt?

Edit: Okay, die Frage beantwortete ich mir doch selber, es gibt sowas: http://msdn.microsoft.com/en-us/library/…8VS.100%29.aspx

Zitat

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.

Ich will nicht um den heißen Brei reden. Ich gebe dir recht, jedoch will ich auf das überhaupt nicht hinaus
JunggleProgger hat die Problemstellung mit dem dynamic object begonnen, also baue ich meine Antworten darauf auf.
Noch etwas mehr Senf von mir: Wird die Standard Serialisierung von .net verwendet, ist auch keine Kompatibilität gewährleistet.
Klar, wenn ich die Serialisierung selbst implementiere.... logisch.

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.

Wenn ich meine Serialisierung selbst schreibe, kann ich genauso andere Speicherarten selbst schreiben. Plain-text, XML, etc. die mit einem dynamic arbeiten können.

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?

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.

Unsererseits hat niemand von der Standardimplementierung zur Serialisierung aus dem .NET Framework geschrieben, sondern von dem Konzept, zur Laufzeit vorhandene Objekte in eine persistent speicherbare Form umzuwandeln, aus der bei einer späteren Ausführung diese Objekte wieder erzeugt werden können.
Und bei allem, was wir jetzt beschrieben haben, braucht man kein dynamic. Der gewünschte Typ ist in diesem Fall bekannt, ob ein Dictionary<String, String> oder eine eigene Klasse mit mehr Funktionalitäten. Darüber sollte man die gesamte Funktionalität erreichen können, die man benötigt.

Legend wollte wohl darauf hinweisen, dass wohl doch nicht immer einfach Properties erzeugt werden, wenn diese gerade nicht da sind. (Wenn das wirklich nur mit Objekten dieses Typs geht, dann ist es für die Deserialisierung nicht zu gebrauchen, da man danach eigentlich sein eigenes Objekt mit bestimmten Methoden haben will und nicht nur mit diversen Eigenschaften.)

Bisher klingt es sehr danach, als würdest du eine Verwendung von dynamic (sei es nun allgemein oder für diesen speziellen Fall) befürworten. Ich finde aber, dass man in einer Sprache, die eine Typisierung der Variablen unterstützt, man seinen Variablen passende Typen zuweisen sollte. Dadurch wird nicht nur die Lesbarkeit des Codes gefördert, sondern dem Entwickler können außerdem bessere Hilfsmittel (Autovervollständigung, Fehleranzeige vor der Ausführung der Codes) angeboten werden.

@Sacaldur
++ Möchte dir nicht widersprechen. Es hieß jedoch "Serialisierung" von beginn an. Und bei Serialisierung verstehe ich die Standard von .net angebotene Serialisierung.

Zitat von »Toemsel«

Wird die Standard Serialisierung von .net verwendet, ist auch keine Kompatibilität gewährleistet.

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.

Zitat von »Toemsel«

Und bei Serialisierung verstehe ich die Standard von .net angebotene Serialisierung.

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.

Dann ist ja gut, dass darauf hingewiesen wurde, dass wir uns nicht darauf bezogen.

Ich weiß nicht, wie es bei BlueCobold ist, ich für meinen Teil versuche solche Beschreibungen möglichst allgemeingültig zu halten. Wenn ich also von Serialisierung oder Events schreibe, meine ich die abstrakten Konzepte und nicht die speziellen Ausprägungen einer Sprache oder einer Bibliothek.
Der Vorteil dabei ist, dass sich die beschriebenen Dinge auch in anderen Sprachen verwenden lassen. Während man in C# delegates und events hat, hat man in Java eine Sammlung von EventListenern, die eine bestimmte Schnittstelle implementieren, aber beides wurde auf die gleiche Weise beschrieben.