Property via AsString;AsInteger;AsBoolean;.. laden

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

Hast meinen Post oben schon gesehen?

Default-Werte solltest du im Konstruktor setzen. Dafür ist er da.

Und warum denn bitte Variant nehmen? Die ganze Typsicherheit geht verloren und du bekommst erst zur Laufzeit Probleme, da der Compiler die Typen nicht schon beim Compilieren prüfen kann.

**Thom**

@-=ZGD=-:

Gut, dann müßtest Du natürlich vorher den Inhalt des Variant-Wertes testen:

markieren

Delphi-Quellcode:

			  if VarIsType(Items['xxx'],varInteger)

    then IntegerWert:=Items['xxx']

    else IntegerWert:=IntegerDefault;

Willst Du diesen Test innerhalb Deines Objektes unterbringen, ist die Verwendung von Variant ungünstig und ich würde an Deiner Stelle auch Records nehmen.

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

Und warum denn bitte Variant nehmen? Die ganze Typsicherheit geht verloren und du bekommst erst zur Laufzeit Probleme, da der Compiler die Typen nicht schon beim Compilieren prüfen kann.

Dafür gibt es Tests... Und es gibt Sprachen, die bauen ausschließlich auf Variant auf (z.B. JavaScript).

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

Warum es erst zur Laufzeit krachen lassen, wenn mir schon der Compiler sagen kann, dass das was schief laufen wird?

Läuft doch nur darauf hinaus, dass ich jeden Käse abfragen muss, bevor ich dann die eigentliche Variable nutzen kann. Und den Vorteil von den Variants sehe ich dann einfach nicht, tut mir Leid. Zudem erzeugst du so eher mehr Code und Unsicherheit, was es doch nicht brauch.

Zudem stell dir mal die Situation vor, dass ein Kollege deinen Code nutzen will und nicht weiß, was er denn für Daten bekommt. Ist der Wert von der "Variable" Index nun vom Type string oder Integer? Oder gar ganz was anderes. Was soll er denn mit Variant anfangen können? Erst mal die komplette Doku lesen, obwohl IntelliSense ihm sagen könnte "Hey, Index ist vom Typ string".

Zitat:

Dafür gibt es Tests... Und es gibt Sprachen, die bauen ausschließlich auf Variant auf (z.B. JavaScript).

Nur weil es Sprachen gibt, die darauf aufbauen -- wobei ich nicht wirklich weiß, wie JS das handhabt -- heißt es ja auch noch lange nicht, dass es gut ist. JavaScript und PHP haben mich oft genug mit diesem varianten Gehabe gestört. Wenn ich auf einmal aus einem string eine Klasse generieren kann, ist das vielleicht schon recht nett, aber man läuft echt in viele Probleme rein. Typsicherheit bringt auf jedenfall mehr Aufbau, sichert aber eben auch sehr viel zu, auf das man sich verlassen kann.

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

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

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