"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 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 F dabei berücksichtigt und zusätzlich aber auch noch das Attribut 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 FsomeField benennen? Weil du in den Ableitungen das als 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 von Sir Rufo:

Grundproblematik ist eben die Konvention, dass die Felder einer Klasse automatisch den Prefix F bekommen. [...]
Warum kannst du dein Feld nicht einfach FsomeField benennen?

Bitte nicht

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 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?

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.

[Uwe Raabe]

Zitat von Sir Rufo:

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 von 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

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

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.

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

'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 von Der schöne Günther:

Woher soll ich die Weisheit mit F eigentlich nehmen?

Object Pascal Style Guide