Property via AsString;AsInteger;AsBoolean;.. laden

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

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;