Property via AsString;AsInteger;AsBoolean;.. laden

**Thom**

Ich verstehe Dein Problem mit Variant nicht. Dafür gibt es, wie schon geschrieben, entsprechende Tests. Da "kracht" gar nichts.
Außerdem wird ja keiner gezwungen, den Typ Variant zu verwenden. Er hat - wie alle anderen Herangehensweisen auch - Vor- und Nachteile.

Nachtrag
Da Du Deinen Beitrag inzwischen geändert hast, muß ich auch noch etwas ergänzen:
Da ganze läuft wieder auf "meine Variante ist viel besser als Deine" heraus und reiht sich wunderbar in die ganzen sinnlosen Diskussionen wie "FreeAndNil ist schlecht", "globale Variablen sind böse", "wer ohne Entwurfsmuster arbeitet hat keine Ahnung" ein. Hängen wir also noch ein "Variant ist böse" dran.
Und damit bin ich weg...

**s.h.a.r.k**

Ich sage doch nur, dass aus meiner Sicht, Variants nicht der Typsicherheit vorgezogen werden sollte -- es gibt ja in der Zwischenzeit auch nicht um sonst die Generics.

Klar gibt es Tests, aber die werden erst zur Laufzeit ausgeführt und nicht zur Compilezeit. Und es ist wohl schöner eine einfache Zuweisung zu haben, als dass ich mehrere Abfragen einbauen muss. Klar die Konvertierung beim Einlesen einer Konfiguration ist ein Mehraufwand, den man bei Variants nicht hat, aber den Variants muss ich ständig kritisch gegenüber stehen und prüfen, ob da auch was valides drin steht. Jedes mal wenn ich darauf zugreife. Was glaubst du, wie es denn deinem Kollegen geht, der deinen Code nutzt, wie im Beispiel oben erwähnt?

Ich habe bisher echt noch nie so wirklich einen Variant genutzt, vor allem ab Delphi2010 und den Generics. Nicht nur aufgrund der Typsicherheit, sondern auch aufgrund der Performance.

**Thom**

@s.h.a.r.k:

Die Performance habe ich noch nicht verglichen. Ob es zwischen dem zusätzlichen Code, der von Compiler für Variant erzeugt wird und dem, der durch eigene Konvertierungen entsteht, signifikante Unterschiede gibt, müßte man einmal testen.
Aber wie schon geschrieben: Variant ist kein Wundermittel und hat seine Grenzen - wie jede andere Lösung auch. Generics sind ebenfalls kein Allheilmittel. Ich denke, es kommt immer auf den Programmierer an, eine für den konkreten Fall optimierte Lösung zu finden.

Ich bin absolut kein Freund von JavaScript - auch wenn/obwohl/gerade weil ich mich intensiv damit beschäftig habe. Aber es gibt dort Konstruktionen, die sich nur mit extrem großem Aufwand oder eben gar nicht mit einer typsicheren Sprache wie Delphi umsetzen lassen. Anders herum werden Entwickler, die es nicht gewohnt sind, sich mit dem Typ von Parametern und Variablen auseinanderzusetzen, sehr schwer tun, Delphi einzusetzen. Typ oder Nicht-Typ - das ist alles eine Frage der Gewöhnung. Es aber gleich als schlecht abzutun, weil man es selbst nicht gewohnt ist, ist aber auch nicht der richtige Weg...

**-=ZGD=-**

Zitat von Thom:

@s.h.a.r.k:

Die Performance habe ich noch nicht verglichen. Ob es zwischen dem zusätzlichen Code, der von Compiler für Variant erzeugt wird und dem, der durch eigene Konvertierungen entsteht, signifikante Unterschiede gibt, müßte man einmal testen.
Aber wie schon geschrieben: Variant ist kein Wundermittel und hat seine Grenzen - wie jede andere Lösung auch. Generics sind ebenfalls kein Allheilmittel. Ich denke, es kommt immer auf den Programmierer an, eine für den konkreten Fall optimierte Lösung zu finden.

Ich bin absolut kein Freund von JavaScript - auch wenn/obwohl/gerade weil ich mich intensiv damit beschäftig habe. Aber es gibt dort Konstruktionen, die sich nur mit extrem großem Aufwand oder eben gar nicht mit einer typsicheren Sprache wie Delphi umsetzen lassen. Anders herum werden Entwickler, die es nicht gewohnt sind, sich mit dem Typ von Parametern und Variablen auseinanderzusetzen, sehr schwer tun, Delphi einzusetzen. Typ oder Nicht-Typ - das ist alles eine Frage der Gewöhnung. Es aber gleich als schlecht abzutun, weil man es selbst nicht gewohnt ist, ist aber auch nicht der richtige Weg...

Performance ist mir vollkommen egal, da nur beim Start der Anwendung die lokale Konfiguration gelesen wird.
Ob da nun 200ms oder 1000ms dauert, damit können die Anwendung und auch ich leben.

Ich suche einfach nach einer schneller, guten und dauerhaften Lösung.
Die Klasse wird einmal geschrieben und dann nie wieder im Code angefasst, weil sie eben genau das tut, was sie soll: Konfigurationen lesen und schreiben.

Ich arbeite sowohl mit Delphi, PHP und auch Javascript und das schon seit Jahren. Es gibt nur eben Themen (RTTI, Generics) mit denen ich mich noch nicht beschäftigt habe, dass aber zu gegebenem Zeitpunkt und in Ruhe tun werde.
Wohlmöglich sehe ich dann die Config-Klasse anders, warum auch nicht.

Das alles sein Für und Wider hat, dagegen ist nichts einzuwenden. Letztlich entscheidet das Gutdünken des Entwicklers darüber, wie er es lösen möchte.

Ich möchte letzten Endes einfach die 230 Codezeilen so haben, dass diese funktionieren

**s.h.a.r.k**

Wenn du den Implicit-Operator überladen würdest, solltest du deine Setter-Methode so belassen können, wie du es hast. Mal schnell aus dem Kopf heraus aufgeschrieben:

zusammenfalten · markieren

Delphi-Quellcode:

			TBlub = class

private

  FRec : TMyRecord;

  procedure SetRec(Value: TMyRecord);

public

  property Rec : TMyRecord read FRec write SetRec;

end;

procedure TBlub.SetRec(Value: TMyRecord);

begin

  FRec := Value;

end;

TMyRecord = class

private

  FValue : Integer;

public

  operator Implicit(Value: Integer): TMyRecord;

  property Value : Integer read FVaule;

end;

TMyRecord.Implicit(Value: Integer): TMyRecord;

begin

  Result.FValue := Value;

end;

**-=ZGD=-**

Hab ich gesehen Shark, etwas zu spät.

Hmm, mit RTTI möchte ich eigentlich nicht arbeiten, frag mich nicht warum, aber ich schau mir das in der Freizeit gern mal an.

Naja, Variant hält mir einfach die Flexibilität offen.
Für mich macht es im Moment mehr Sinn, wenn ich einfach sagen kann myConfig.Items['iwas'].AsBoolen und ich dann schon fertig meine Konvertierung, whatever gemacht habe.

Der Hintergrund ist total simpel: Ich habe eine SQLite-3-Datenbank in welcher eine Tabelle

markieren

Code:

config

ist mit den Feldern

markieren

Code:

key, value

.

markieren

Code:

value

kann jeden beliebigen Wert annehmen.

Steht da jetzt -1 drin, kann ich genauso mit

markieren

Code:

.AsInteger

, als auch mit

markieren

Code:

.AsBoolean

Abfragen gestalten.
Das ist einfach n Stück weit flexibel, ohne dass ich andere Entwickler mit strikten Typen bewerfen muss.

markieren

Code:

.AsInteger, .AsString, .AsBoolean, ...

sind einfach vom Query abgekupfert.

Es funkioniert wie ich es haben wollte bereits lesender Weise. Mir fehlt nur noch das

markieren

Code:

SET

.
Hierzu eine Idee?

PS Ich bin von Variant im Moment nicht abzubringen

**s.h.a.r.k**

Aus welchem Grund will ich einen Boolean-Wert auf -1 abfragen? Was hat das denn mit Flexibilität zu tun? Es ist entweder ein Boolen oder ein Integer oder ein string. Gut, der einzige Vorteil, den ich gerade sehe ist, dass ich dem Variant auch eien Null-Wert geben kann, das lasse ich mir eingehen. Dafür gibts aber einen generischen Nullable-Typ, entweder einen selbst geschriebenen oder gleich der vom Spring-Framework.

Finde es jedenfalls etwas seltsam bei jedem Aufruf wissen zu müssen, welchen Datentyp, denn gerade vorliegen soll, in der Hoffnung, dass dann auch das passende im Variant drin steht. Klar, wenn das System nicht groß ist und nicht viele Einstellungen hat, dann ists noch überschaubar. Aber ständig die Doku neben dran liegen zu haben und nachschauen zu müssen, welche Variable von welchem Typen ist... Und das wird dir, wenn du die Software wartest, irgendwann mal passieren, da du nicht jeden Tag den Code in den Fingern hast.

Wo liegt das Problem beim Setter? Füge dem Record ein SetValue() hinzu und gut is.

**-=ZGD=-**

Zitat von s.h.a.r.k:

Aus welchem Grund will ich einen Boolean-Wert auf -1 abfragen? Was hat das denn mit Flexibilität zu tun? Es ist entweder ein Boolen oder ein Integer oder ein string. Gut, der einzige Vorteil, den ich gerade sehe ist, dass ich dem Variant auch eien Null-Wert geben kann, das lasse ich mir eingehen. Dafür gibts aber einen generischen Nullable-Typ, entweder einen selbst geschriebenen oder gleich der vom Spring-Framework.

Finde es jedenfalls etwas seltsam bei jedem Aufruf wissen zu müssen, welchen Datentyp, denn gerade vorliegen soll, in der Hoffnung, dass dann auch das passende im Variant drin steht. Klar, wenn das System nicht groß ist und nicht viele Einstellungen hat, dann ists noch überschaubar. Aber ständig die Doku neben dran liegen zu haben und nachschauen zu müssen, welche Variable von welchem Typen ist... Und das wird dir, wenn du die Software wartest, irgendwann mal passieren, da du nicht jeden Tag den Code in den Fingern hast.

Wo liegt das Problem beim Setter? Füge dem Record ein SetValue() hinzu und gut is.

Du frägst keinen Boolean auf -1 ab, aber das wäre in dem Falle ein TRUE und ist selbiges Feld als Integer -1 kannst du genauso damit arbeiten und zum Beispiel Werte einfach negieren, wenn du es *-1 nimmst.
Jetzt nicht den Kopf zerbrechen, warum und woher..

Pass auf:

markieren

Code:

			KEY | VALUE

dbhost | localhost

dbport | 3306

dbuser | root

...

Das wäre jetzt ein Auszug aus der Config-Tabelle.

Bisher wurde alles als String ausgelesen.
Nun kann ich meiner Port-Komponente keinen String zuweisen. Daher die Intention

markieren

Code:

.AsInteger

So, die Doku muss der Entwickler sowieso bei sich haben, damit er weiß, welche Konfigurationfelder er eigentlich hat, da ist´s egal, dass er noch schaut und liest: Typ.INTEGER.

property Item[aKey: String]: RConfig2 read GetVariantValue write SetVariantValue; SetVariantValue ist ein Prozedur procedure SetVariantValue(aID: String; aValue: Variant); .

Ich hab auch schon versucht,

markieren

Code:

RConfig2

zu übergeben, aber ich scheitere...

**Iwo Asnet**

Wir arbeiten hier seit Jahren mit dem Vorschlag von Thom (Variants).

Unsere Lösung ist so banal, das wir auf Typensicherheit, OOP, CleanCode usw. an der Stelle verzichten. Die Unit ist 186 Zeilen lang und implementiert einen bösen Singleton namens 'Setup'. Fertig.

Wir verwenden die Eigenschaften 'AsInteger', 'AsString', 'AsBoolean', um komfortabler auf Daten zugreifen zu können (nötig ist das nicht):

markieren

Delphi-Quellcode:

			ValueAsVariant := Setup['MySetting'];

ValueAsInteger := Setup.AsInteger['MyIntegerSetting'];

ValueAsBoolean := Setup.AsBoolean['MyBooleanSetting'];

...

Wir hatten bisher nie die Muße, über den Sinn zu diskutieren. Die Unit wurde in 30 min zusammengebaut und funktioniert.

Nein, und unsere Anwendungen haben keine 1000 Einstellungen. Höchstens 20.

Wer mit Metadaten arbeitet (und hier haben wir welche), sollte sich mit den Variants vertraut machen.

**-=ZGD=-**

Zitat von Iwo Asnet:

Wir arbeiten hier seit Jahren mit dem Vorschlag von Thom (Variants).

Unsere Lösung ist so banal, das wir auf Typensicherheit, OOP, CleanCode usw. an der Stelle verzichten. Die Unit ist 186 Zeilen lang und implementiert einen bösen Singleton namens 'Setup'. Fertig.

Wir verwenden die Eigenschaften 'AsInteger', 'AsString', 'AsBoolean', um komfortabler auf Daten zugreifen zu können (nötig ist das nicht):

markieren

Delphi-Quellcode:

			ValueAsVariant := Setup['MySetting'];

ValueAsInteger := Setup.AsInteger['MyIntegerSetting'];

ValueAsBoolean := Setup.AsBoolean['MyBooleanSetting'];

...

Wir hatten bisher nie die Muße, über den Sinn zu diskutieren. Die Unit wurde in 30 min zusammengebaut und funktioniert.

Nein, und unsere Anwendungen haben keine 1000 Einstellungen. Höchstens 20.

Wer mit Metadaten arbeitet (und hier haben wir welche), sollte sich mit den Variants vertraut machen.

Meine Worte

Bei mir werden es auch nicht mehr als 50 Werte werden.

Ich finde diese Lösung eben einfach und alltagstauglich. Man muss nicht alles auf die Spitze treiben.

@Shark: Ich habe doch einen Setter im Record..wo finde ich meinen Fehler?