"F"-Prefix beim TJSONUnMarshal

[Der schöne Günther]

Ich wollte grade ganz unbedarft in die Materie einsteigen. Ich weiß nichts über JSON. XE7.

Embarcaderos Blog-Beitrag "How to convert an object to JSON and back with a single line of code" sah hier schon sehr vielversprechend aus.


Folgendes Beispiel:

Project1.DPR

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}
{$R *.res}

uses
   System.SysUtils,
   System.JSon,
   Rest.Json,
   MyTypeUnit in 'MyTypeUnit.pas';

var
   jsonObj: TJSONObject;
   regularInst: TMyType;
   copiedInst: TMyType;

{ TMyType }

begin
   regularInst := TMyType.Create(99);

   jsonObj := TJSON.ObjectToJsonObject(regularInst);
   asm nop end;
   WriteLn( jsonObj.ToJSON() ); // Ergibt {"someField":99,"fieldWithStupidName":99}

   copiedInst := TJson.JsonToObject<TMyType>(jsonObj);
   // copiedInst hat in someField Feld eine 42!

   readln;
end.

MyTypeUnit.pas

Delphi-Quellcode:

unit MyTypeUnit;

interface

type
   TMyType = class(TObject)
      protected var
         someField: Integer;
         FFieldWithStupidName: Integer;
      public
         constructor Create(); overload;
         constructor Create(const initValue: Integer); overload;
   end;

implementation uses System.SysUtils;

constructor TMyType.Create();
begin
   inherited Create();
   someField := 42;
   FFieldWithStupidName := 100;
end;

constructor TMyType.Create(const initValue: Integer);
begin
   inherited Create();
   someField := initValue;
   FFieldWithStupidName := initValue;
end;

end.

Das Problem:
Die Kopie bekommt das Feld "FFieldWithStupidName" richtig gesetzt, das Feld "someField" nicht.
Wie man in der Konsolenausgabe sieht kürzt der Kerl den "F"-Prefix bei Feldnamen weg. Beim Weg JSON->TObject wird er es wohl wieder davorsetzen.

Der Workaround:
Ich muss all meinen Feldern das Attribut JSonName mitgeben:

Delphi-Quellcode:

   TMyType = class(TObject)
      protected var
         [JSonName('someField')]
         someField: Integer;
         FFieldWithStupidName: Integer;
      public
         constructor Create(); overload;
         constructor Create(const initValue: Integer); overload;
   end;

Meine Frage:
Wie kann ich das vermeiden- Wo kann ich einstellen dass er bitte die Felder auch alle so serialisieren soll, wie sie tatsächlich heißen?

[Sir Rufo]

Grundproblematik ist eben die Konvention, dass die Felder einer Klasse automatisch den Prefix

Delphi-Quellcode:

F

bekommen.

Delphi-Quellcode:

TFoo = class
private
  FVal : string;
public
  property Val : string read FVal write FVal;
end;

Bei der Serialisierung werden aber eben nicht die Properties, sondern die Felder serialisiert (was auch gut ist). EMBA hat nun einfach dieses Prefix

Delphi-Quellcode:

F

dabei berücksichtigt und zusätzlich aber auch noch das Attribut

Delphi-Quellcode:

JSonName

eingeführt.

Damit ist doch alles gut. Benenne die Felder nach der Konvention oder hänge ein Attribut an das Feld.
Warum kannst du dein Feld nicht einfach

Delphi-Quellcode:

FsomeField

benennen? Weil du in den Ableitungen das als

Delphi-Quellcode:

someField

verwenden möchtest?

Kein Problem:

Delphi-Quellcode:

type
  TMyType = class(TObject)
  private
    FsomeField : Integer;
    FFieldWithStupidName: Integer;
  protected
    property someField: Integer read FsomeField write FsomeField;
    property FieldWithStupidName: Integer read FFieldWithStupidName write FFieldWithStupidName;
  end;

[Der schöne Günther]

Danke für die Antwort :-)

Zitat:

Zitat von Sir Rufo (Beitrag 1274413)

Grundproblematik ist eben die Konvention, dass die Felder einer Klasse automatisch den Prefix

Delphi-Quellcode:

F

bekommen. [...]
Warum kannst du dein Feld nicht einfach

Delphi-Quellcode:

FsomeField

benennen?

Bitte nicht :cry:

All mein Hass diesen prähistorischen Variablen-Prefixen. Wir haben uns von dieser Konvention eigentlich komplett gelöst. Da bleibe ich lieber bei völlig unnötigen Attributen für die Felder.

[Sir Rufo]

Kann ich nicht nachvollziehen, denn ich benutze diesen Prefix andauernd und sehe keine Nachteile, sondern nur Vorteile.

Anhand des Prefix sehe ich sofort aus welchem Scope die denn nun kommt:

• Field
• Argument
• Local

Aber jeder wie er will ;)

[himitsu]

Zitat:

Zitat von Sir Rufo (Beitrag 1274413)

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?

Zitat:

Aber jeder wie er will

Lokale Sachen bekommen bei mir keinen Prefix (Argument und Local), sondern nur "Globale" (Typen und Felder), welche außerhalb des Blickfeldes liegen.
Das ist ja IMHO fast soeine Unsitte, wie die TypPrefixe bei bei den Argumenten/Feldern, welche man z.B. aus'm C++ kennt. :stupid:

[Uwe Raabe]

Zitat:

Zitat von Sir Rufo (Beitrag 1274416)

Aber jeder wie er will ;)

Sehr richtig!

Ich habe allerdings die Erfahrung gemacht, daß es häufig besser ist, sich mit den Standards seines Entwicklungswerkzeugs anzufreunden, als denen entgegen zu arbeiten. Das fängt schon bei den Namens-Konventionen und der Code-Formatierung an. Schon vor geraumer Zeit habe ich mich in diesen Punkten weitestgehend den Delphi-Sourcen angepasst. Das erfordert zum Einen kein Umdenken, wenn ich meine eigenen oder die Delphi-Sourcen lese, und zum Anderen gibt es auch keine Hakelpunkte, die integrierter Code-Formatierung an diese Vorgaben anzupassen (die stimmen nämlich schon bei der Installation).

[Dejan Vu]

Zitat:

Zitat von Sir Rufo (Beitrag 1274416)

Kann ich nicht nachvollziehen, denn ich benutze diesen Prefix andauernd und sehe keine Nachteile, sondern nur Vorteile.

Anhand des Prefix sehe ich sofort aus welchem Scope die denn nun kommt:

• Field
• Argument
• Local

Aber jeder wie er will ;)

Bei mir ergibt sich das aus aus der Tatsache, das Methoden so klein sind, das sie auf eine (Bildschirm-) Seite passen und private Felder nur im Getter und Setter sowie im Konstruktor angefasst werden. Damit fällt schon mal das 'F' weg (bzw. könnte). Argumente und lokale Variablen gibt es eh nicht viele in einer Methode und wenn ich mal wissen muss, ob 'X' ein Argument ist oder nicht, geh ich mit dem Cursor rauf.

Nachteile? Na ja, es heißt nicht 'LTotalSize', sondern 'total size' (im englischen) und daher leidet die Lesbarkeit (=> Clean Code).

Aber Delphi ist Delphi und da ist das (zumindest mit den Feldern) so. Und wenn das so usus ist, dann macht man das eben. Man will ja nicht unangenehm auffallen.

Übrigens habe ich das 'a' bei einem Parameter immer als 'ein' gelesen, also 'a Customer' und dann eben folgerichtig 'anObject'. Das ist dann wenigstens lesbar und hat auch irgendwie etwas Logisches, denn eine lesbare Methode mit einem Kunden-Argument ist eben 'Save(aCustomer : TCustomer)'.

Aber wie sagst Du so schön: Jeder wie er will...

[Der schöne Günther]

Rest.JsonReflect.pas:

Delphi-Quellcode:

function TJSONUnMarshal.ConvertFieldNameFromJson(AObject: TObject; const AFieldName: string): string;
[...]
    // Delphi Fieldname usually start with an "F", which we don't have in JSON:
    // FName = 'Elmo'  => {"Name":"Elmo"}
                                        
    LFieldName := 'F' + AFieldName;
    Result := LFieldName;
[...]

Fest einkodiert. All mein Hass. Ganz ehrlich... :kotz:

Hätte man das nicht wenigstens einstellbar machen können?

Im "Delphi Language Guide: Fields" wird auch nichts mehr mit F-geprefixed. Woher soll ich die Weisheit mit F eigentlich nehmen?

Ganz abgesehen davon dass in der Dokumentation zu Json darüber auch nicht das geringste zu finden ist. :hello: :roteyes:

[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. 'Außen' ist irgendwie 'öffentlich', also so 'publik' machen oder 'publizieren' oder wie man das nennt. Wie heißt das doch gleich auf Englisch? :wall:

'Teeren und Federn' war zu meiner Zeit das adäquate Mittel, den Programmierer für derartige Ergüsse öffentlich zu würdigen.

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1274457)

Woher soll ich die Weisheit mit F eigentlich nehmen?

Object Pascal Style Guide

[Der schöne Günther]

Zitat:

Zitat von Uwe Raabe (Beitrag 1274463)

Zitat:

Zitat von Der schöne Günther (Beitrag 1274457)

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. :kiss::love:

[mjustin]

Zitat:

Zitat von Dejan Vu (Beitrag 1274461)

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:

Zitat von himitsu (Beitrag 1274419)

Zitat:

Zitat von Sir Rufo (Beitrag 1274413)

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. :warn:


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:

Zitat von mjustin (Beitrag 1274466)

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:

Zitat von Sir Rufo (Beitrag 1274470)

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

Delphi-Quellcode:

transient

-Direktive für Felder kenne ("Bitte nicht serialisieren") geht hier natürlich auch mit dem Delphi-Attribut

Delphi-Quellcode:

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

Delphi-Quellcode:

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:

Zitat von Sir Rufo (Beitrag 1274475)

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;

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

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1274464)

Zitat:

Zitat von Uwe Raabe (Beitrag 1274463)

Zitat:

Zitat von Der schöne Günther (Beitrag 1274457)

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.

Meines Wissens gibt es keine neueren Styleguides. Verwechselst du vielleicht den Delphi Language Guide mit dem Object Pascal Style Guide? Das sind zwei völlig verschiedene Dinge. In dem einen wird die Sprache beschrieben und in dem anderen die Coding Convention von Borland/InPrise/CodeGear/Embarcadero.

Übrigens finde ich es gerade gut, daß der Styleguide bereits so alt ist wie Delphi. So muss man den ganzen Code nicht bei jeder Änderung des Styleguide umschreiben.

[Dejan Vu]

Es ist doch aber zweitranging, ob das 'F' nun in irgendwelchen Styleguides steht oder nicht oder wie alt die sind und ob sich Emba an den eigenen Styleguide hält oder nicht (eher nicht).

Ich kann doch die Funktionsweise einer Klasse/Bibliothek nicht davon abhängig machen, wie ich meine privaten Teile benenne.

[Uwe Raabe]

Zitat:

Zitat von Dejan Vu (Beitrag 1274502)

Es ist doch aber zweitranging, ob das 'F' nun in irgendwelchen Styleguides steht oder nicht oder wie alt die sind und ob sich Emba an den eigenen Styleguide hält oder nicht (eher nicht).

Ich kann doch die Funktionsweise einer Klasse/Bibliothek nicht davon abhängig machen, wie ich meine privaten Teile benenne.

Ich gebe dir da uneingeschränkt recht! Man hat es dennoch getan...

Es geht mir auch gar nicht um eine Wertung dieser Implementation, sondern ein Verhalten aufzuzeigen, das einen Umgang damit erleichtert.

[Dejan Vu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1274506)

Es geht mir auch gar nicht um eine Wertung dieser Implementation, sondern ein Verhalten aufzuzeigen, das einen Umgang damit erleichtert.

Die Konventionen? Na, wenn's denn sein muss.

Blöderweise muss man dann auch über jede Klasse einen Warnhinweis schreiben, das private Felder unbedingt mit 'F' anfangen müssen. Und Unittests, die die Nomenklatur sicherstellen. Und da gehört sowas normalerweise nicht rein. Einfach unsauber, der Ansatz. Und da kriejisch Plack, Krätse und so'n Hals. ;-) Jammern auf hohem Niveau halt-