"F"-Prefix beim TJSONUnMarshal

[himitsu]

Und genau darum sollte man automatisch ausschließlich die öffentlichen Dinge kopieren. (siehe TPersistent/TComponent und DFM)
Maximal kann das Objekt noch über eine Methode für das Serialisieren spezieller interner Strukturen anbieten. (siehe TComponent.ReadState und TComponent.WriteState)

Wieso sollte die Serialisierung z.B. ein Handle/Pointer des internen Feldes speichern, anstatt die Daten des öffentlichen Properties?

Genauso wie "standardmäßig" anderer Code gefälligst auf das Property zuzugreifen hat und nicht auf das private/interne Feld, so hat das auch eine Serialisierung gefälligst nicht zu tun, da sie garnicht wissen kann, wie man die internen Werte zu interpretieren hat.


Man macht ein Foto von deinem Häuserblock und will nun, ein Jahr später, den Zustand wiederherstellen:
* Sollen die nun einfach in deine Wohnung gehen und die Gardinen genauso auf-/zuziehen und die Lampen an-/ausschalten
* oder sollen sie dich fragen/dir sagen in welchem Fenster wie das Licht auszusehen hat?

Die wissen ja noch nichtmal welche Lampen man wo anschalten kann.
Sie können zwar der Glühbirne gern sagen "geh an", aber du weißt wo der Schalter sich versteckt und wie man ihn bedient.

Zitat:

Und wie macht man das bei so einem Objekt ohne auf die Felder zuzugreifen?

Entweder garnicht , wenn das Objekt keine Serialisierung anbietet,
oder das Objekt bietet eine Funktion an, welche beim Serialisieren den Zustand von FState "freiwillig" rausgibt und beim Deserialisieren den Wert/Zustand wieder entsprechend herstellt.


Kopiere den Inhalt des RAM eines Programms und später lade den Inhalt "blind" wieder in einen erstellten Prozess ... danach wird das Programm also wieder genauso aussehen und sich verhalten, wie vorher?
Ich glaube nicht.

[Sir Rufo]

Ok, wir sind da anderer Ansicht.

Allerdings funktioniert das Marshalling nun mal genau so. Über deinen Weg wäre es nicht möglich ohne jede Klasse um so ein zusätzliches Geraffel zum Serialisieren zu erweitern.

[himitsu]

Aber ohne jemanden der weiß wie es geht (z.B. ReadState und WriteState), kann man nunmal nicht alles "richtig" deserialisieren.

Entweder man stellt etwas falsch wieder her (Pointer und Handle gespeichert) oder man speichert zuviel.
z.B. Eine Komponente, die einen Kreis auf ein internes Bitmap gemalt hat
* Man kann nun gern das Bitmap Pixel für Pixel speichern
* oder man lässt sich den Zustand "Kreis bei Position X:Y mit D" geben. (welcher vielleicht in einem Pointer rumliegt, dessen Datenformat du garnicht kennst)

Oder eine Font-Instanz in der Komponente, aber mit ParentFont=True ... deine Funktion würde den nun speichern, aber die Klasse weiß, daß es eigentlich sinnlos ist.

[Sir Rufo]

Darum hat man TComponent ja auch die Funktionalität mit dem Streamen mitgegeben.

Denn für diese Art von Klassen ist das Marshalling definitiv nicht gedacht - kann man mal ausprobieren, lässt man aber schnell wieder die Finger von.

Sehr wohl gedacht ist das Marshalling aber z.B. für die kleinen, leichten Klassen wo es Sinn macht, diese z.B. über eine "Leitung" zu schicken, um diese an anderer Stelle wieder zum Leben zu erwecken.

BTW: Es ist sehr einfach Beispiele für die Sinnlosigkeit von jedem beliebigen Werkzeug/Objekt/Entität zu finden:

• Ferrari -> Kann nicht den Acker pflügen! Also Mist!
• Delphi -> Kann nicht für xxx-Exot OS kompilieren! Also Mist!
• Ich -> Kann kein Chinesisch! Also Mist!

Man muss einfach nur das Betrachtende in einem sinnfreien Kontext betrachten, schon ist es obsolet.

[Namenloser]

Zitat von Sir Rufo:

Sehr wohl gedacht ist das Marshalling aber z.B. für die kleinen, leichten Klassen wo es Sinn macht, diese z.B. über eine "Leitung" zu schicken, um diese an anderer Stelle wieder zum Leben zu erwecken.

Klingt für mich ein bisschen, als hätte man Records neu erfunden.

[Dejan Vu]

DTO sind die neuen Records. Alte Idee mit neuem Namen.

Abzulehnen ist so eine "no code" Klasse natürlich nicht, dazu ist sie zu praktisch. Man kann doch aber auf hohem Niveau darüber philosophieren, ob die zu serialisierenden Daten als private- (WT)F-Felder, oder über public properties (als DTO) besser umzusetzen sind.

Wenn man nicht auf die Nase fallen will, sind DTO sowieso zwingend. Finde ich.

@Schöner Günther: Ich würde eben keine *Felder* als Serialisierung nehmen, sondern Eigenschaften. Stellen wir uns mal vor, in XE39 kommen dann auto properties, also

Delphi-Quellcode:

Type
  TFoo = class
    Property Bar : Integer Read; Write;

Und was ist dann mit der 'F' Idee? B*lsh*t. Ehrlich.