TOLEEnum Umwandlung aus String

[Rollo62]

Zitat von Uwe Raabe:

Delphi-Quellcode:

type
  TCountryCodeHelper = record helper for TCountryCode
  private const
    cOleEnums: array[TCountryCode] of Cardinal = (
      CountryCode2_unk,
      CountryCode2_AL,
      CountryCode2_AD,
      ...
      );
    function GetAsOleEnum: Cardinal;
    function GetAsString: string;
    procedure SetAsOleEnum(const Value: Cardinal);
    procedure SetAsString(const Value: string);
  public
    property AsOleEnum: Cardinal read GetAsOleEnum write SetAsOleEnum;
    property AsString: string read GetAsString write SetAsString;
  end;

Hallo Uwe,

ich nutze sowas in der Art, aber verzichte auf die Properties.

Delphi-Quellcode:

type
  TCountryCodeHelper = record helper for TCountryCode
    function AsOleEnum : Cardinal;
    function AsString  : String;
  end;

Welchen Vorteil hätte ich, wenn ich an dieser Stelle Properties benutze?
Ich meine Funktionen machen das genauso, oder übersehe ich da etwas?

Sorry, es ging Dir ja um Setter und Getter, dann ist es klar.

Ich mache das mehr so, weil es nicht immer passende Konvertierungen gibt.

Delphi-Quellcode:

type
  TCountryCodeHelper = record helper for TCountryCode
    function ToOleEnum : Cardinal;
    function TryFromOleEnum( AVal : Cardinal ) : Boolean;     

    function ToString  : String;
    function TryFromString( AVal  : String ) : Boolean;
  end;

[Uwe Raabe]

Zitat von Rollo62:

Ich mache das mehr so, weil es nicht immer passende Konvertierungen gibt.

Bei den Settern ist das durchaus sinnvoll. Da es hier aber ein dediziertes Unknown gibt, kann man halt das als Fallback verwenden. Kommt immer auf die Verwendung an.

Die Getter müssen indes immer liefern können. Alles andere wäre ein Programmierfehler (zumindest bei dieser Art Anwendungsfälle). Bei der String-Rückgabe von unk könnte man über einen Leerstring diskutieren, aber das passt dann nicht mehr ganz zum RTTI-Ansatz.

OT: Ich bin eigentlich ein Freund von Properties. Die Anweisungen lassen sich dann einfacher mit dem Reverse Assignment Feature oder dem try-finally-Wizard umdrehen.

[Rollo62]

Zitat von Uwe Raabe:

OT: Ich bin eigentlich ein Freund von Properties.

Ja ich schon auch, aber der Mehraufwand ist halt auch da.
Ist aber richtig, das macht man nur einmal und dann ist es für immer drin

Bei nicht vorhandenem Unknown wäre bei einem Getter ja nur noch eine Exception möglich,
was ich persönlich für den einfachen Enum ( <> Integer ) etwas zu hart finde.
Deshalb bevorzuge ich TryFromXyz, da kann ich dann explizit drauf reagieren.

Ich nutze das oft um enum => Integer oder enum => String und zurück umzuwandeln, z.B. für Serialisierung oder Persistance.
Dabei sollte es meiner Meinung nach besser einen 1:1 Match geben, auch bei Unknown, und keinen Fallback, was zu Misinterpretation führen könnte.

Nur wenn es eben nicht exakt in das Enum reinpasst, dann gäbe es den Abbruch bei TryFromXyz.
Das kann z.B. durch Versionsupdates oder ähnliches leicht passieren.

[Humbucker]

Hallo Uwe,
ich habe den Record Helper verwendet und es funktioniert sehr gut. Vielen Dank für den Beispielcode. Auch an alle Anderen vielen Dank für eure Hilfe.
VG Michael