TStream in (dp)CollectionItem speichern

[Khabarakh]

Zitat von andreash:

Wieso reicht es nicht aus, TSerializableMemoryStream von TPersistent abzuleiten?

Es reicht natürlich aus, aber warum sollte ich das Interface nicht einbinden?

Zitat:

Und muss es nicht
 destructor Destroy; Override; und im Rumpf

Delphi-Quellcode:

destructor TSerializableMemoryStream.Destroy;
begin
  fStream.Free;
  Inherited;
end;

heißen?

Jupp, ist mir auch aufgefallen (und dann wieder entfallen ). Das kommt davon, wenn man seit fast einem Jahr keine Destruktoren mehr verwendet .

[andreash]

Zitat von Khabarakh:

Zitat von andreash:

Wieso reicht es nicht aus, TSerializableMemoryStream von TPersistent abzuleiten?

Es reicht natürlich aus, aber warum sollte ich das Interface nicht einbinden?

Schade, ich hatte auf ein gutes Argument gehofft, um zu mehr Weisheit zu gelangen.

[mschaefer]

Hm: Weisheit ist relativ (weise)!

Es spart dem Compiler einige Bytes, wenn das Interface direkt eingebunden ist.
Schöner zu lesen ist aber die direkte Ableitung, da sie bei vielen Objekten vergleichbar angewendet wird.

Mich würde immernoch interessieren, ob man die DP-Collection irgendwie in eine XML-Datei bekommt..

Grüße // Martin

[jensw_2000]

Zitat von mschaefer:

Mich würde immernoch interessieren, ob man die DP-Collection irgendwie in eine XML-Datei bekommt..

In TCollection ist kein XML implementiert und in der Child-Class TmxJsCollection (dpCollection) wurde ich kein XML rangestrickt.

Bedeutet also Handarbeit.
Vermutlich wird es aber nicht sehr schwehr einen Parser für nicht-binär abgespeicherte Collections zu schreiben, weil sich die Formate sehr ähneln.

[Khabarakh]

Zitat von mschaefer:

Es spart dem Compiler einige Bytes, wenn das Interface direkt eingebunden ist.
Schöner zu lesen ist aber die direkte Ableitung, da sie bei vielen Objekten vergleichbar angewendet wird.

Öhm... beim Arbeiten mit Interfaces ist das Verkleinern der PE mein letzter Gedanke. Besser gesagt habe ich daran noch nie gedacht. Aber aus modelltechnischer Sicht wäre es doch absoluter Wahnsinn, mehrere Klassen mit den gleichen Methoden (z.B. eben LoadFrom und SaveTo) zu haben, die nicht durch ein gemeinsames Interface normiert sind. Und da die RTL schon ein solches Interface bereitstellt, fiel die Entscheidung noch einmal leichter.