"F"-Prefix beim TJSONUnMarshal

[Der schöne Günther]

Zitat von Uwe Raabe:

Zitat von Der schöne Günther:

Woher soll ich die Weisheit mit F eigentlich nehmen?

Object Pascal Style Guide

Das Enthält ein "Copyright 1995". Da bin ich noch aufs Töpfchen gegangen.

Meine Ausrede steht weiterhin. Die "aktuellen" Styleguides sprechen überhaupt nicht mehr von einem F in Feldern.

Und ja, ich habe grade schlechte Laune.

[mjustin]

Zitat von Dejan Vu:

Was für ein Dreck.
Unterm Strich ist es ja ganz brauchbar, den 'inneren Zustand' eines Objekts zu (de-)serialisieren, aber das ist einfach nicht etwas, was man als JSON (oder XML) nach außen geben sollte.

Warum 'sollte' man es nicht können? Sicherheitsbedenken kann man natürlich anführen, über Serialisierung kann man immer auch "private" Daten eines Objektes extern sichtbar machen. Aber alle privaten Daten sind generell zur Laufzeit sichtbar, da sie irgendwo im Speicher stehen (Beweis: der Debugger kann private Variablen anzeigen).

Nur public/published Daten zu serialisieren wäre sinnfrei, da dadurch der Objektzustand unvollständig erfasst wird.

In der Java Welt kenne ich es so, dass man die Zugriffsmodifizierer (public, private & Co.) als Compile-Time-Feature ansieht und die Serialisierung als Laufzeitfeature. Zweck der Serialisierung ist es einfach nur, ein Objekt in eine Datei- oder anderen Speicherungsform zu konvertieren, die eine spätere Rekonstruktion des Objekts erlaubt. (http://stackoverflow.com/a/4245316/80901)

[Sir Rufo]

Zitat von himitsu:

Zitat von Sir Rufo:

Bei der Serialisierung werden aber eben nicht die Properties, sondern die Felder serialisiert (was auch gut ist).

Eigentlich nicht.

Die Serialisierung hat der interne Aufbau rein garnicht zu interessieren.
Die sollte/darf sich nur nach der Published-Schnittstelle (maximal noch Public) richten.

Also wieso sollte das Ding nun auf die blöde Idee kommen "interne" und vorallem optionale Konventionen anzuwenden, anstatt den "öffentlichen" Namen so zu verwenden, wie er wirklich vorgefunden wurde?

Ganz einfach weil Eigenschaften berechnet, nur lesend, nur schreibend sein können.
Bei der De-Serialisierung kommt es darauf an, die Instanz wieder in den Zustand zu versetzen, wie die Instanz zum Zeitpunkt der Serialisierung war.

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

Delphi-Quellcode:

TFoo = class
private
  FState : Integer;
  function GetIsFinished : Boolean; // Result := FState = 9;
public
  property State : Integer read FState;
  property IsFinished : Boolean read GetIsFinished;

  procedure Step; // if not IsFinished then Inc( FState )
  procedure Reset; // FState := 0;
end;

Code:

{"State":4}

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

[Dejan Vu]

Zitat von mjustin:

Warum 'sollte' man es nicht können? Sicherheitsbedenken kann man natürlich anführen, über Serialisierung kann man immer auch "private" Daten eines Objektes extern sichtbar machen.

"Kann" ja, aber das entscheidet dann das Objekt/die Klasse selbst. Und so sollte es auch sein.

Ich kann dem einfach nichts abgewinnen. Die gleiche 'no code' Funktionalität bekomme ich, wenn ich mir eine DTO-Klasse mit public properties baue und der Serialisierer eben die public properties abgreift. Null Einschränkung, aber die Klasse entscheidet, was im JSON-Telegram sichtbar ist.

So bin ich auch nach gezwungen, die antiquarische 'F'-Notation zu verwenden. Bescheuerter geht es kaum (also der Zwang, nicht die Notation).

Zitat von Sir Rufo:

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.

Eben nicht. Es ginge genau so, wie es in modernen Programmiersprachen gemacht wird (Serialisierung über public properties und Attribute und zur Not, als Hinterausgang, mit einer eigenen Methode).

Wenn man es (so wie ich finde) richtig macht, wird man von ganz alleine schöne saubere DTO bauen und nicht irgendwelche god classes mal eben per JSON verteilen. Also ich finde die Lösung mit dem 'F' Zeugs einfach unsauber.

[Der schöne Günther]

Nein, du siehst es zu schwarz:

Was ich aus Java als transient -Direktive für Felder kenne ("Bitte nicht serialisieren") geht hier natürlich auch mit dem Delphi-Attribut JSONMarshalled(False) . Wie das in .NET heißt weiß ich nicht.

Mich stört nur, dass er dieses F zwangs-voraussetzt, wenn ich nicht mit einem Attribut angebe, mit welchem Namen das Feld serialisiert werden soll. Deshalb bin ich gezwungen, eigentlich redundante Attribute hier zu verwenden wenn ich meine Felder nicht so nennen will. Dieser Zwang ist wirklich vollkommen sinnfrei.



PS: Die gleiche Frage wie meine ("Muss ich das F nehmen?") tauchte auch in Embarcaderos Skill Spring "JSON: The New INI File" (Ab 31:39) auf, wurde aber auch mit "Keine Ahnung, sollte gehen" beantwortet.


PPS: Gibt es in Delphi mehrere fest eingebaute JSON-Marshaller? Ich habe noch einen anderen unter Data.DBXJsonReflect.pas gefunden, und der hat nicht diese "F-Macke". Ich stelle bei Gelegenheit mal eine andere Frage dazu, welche Libraries es gibt und wie sich diese unterscheiden...

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