"F"-Prefix beim TJSONUnMarshal

[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.