"F"-Prefix beim TJSONUnMarshal

[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

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

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

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

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

[Uwe Raabe]

Zitat von Der schöne Günther:

Woher soll ich die Weisheit mit F eigentlich nehmen?

Object Pascal Style Guide