Cast von Nullable<> (Spring4D) nach Variant

[Der schöne Günther]

Ich habe mich vor den Delphi-Variants immer gedrückt und weiß wenig darüber. Hier, was ich glaube:

System.Variants.Null() liefert ein Variant, das bei seinen Casts immer "Null" zurückgibt. Auf eine Zahl ist es 0 , auf einen String ist es ein leerer String, auf eine Referenz ist es Nil usw.

Dementgegen steht System.Variants.Unassigned() : Das liefert einen Variant, der nichts ist. Man kann ihn nirgendwo hin casten, es steckt nichts drin.

Richtig soweit? Wenn ja wundert es mich, warum ein leeresSpring4D-Nullable<> (also mit nichts drin) beim Cast auf ein Variant Null() zurückgibt und nicht Unassigned() .

Welchen Grund hat das? Hier noch einmal der aktuelle Sourcecode in Spring:

Delphi-Quellcode:

class operator Nullable<T>.Implicit(const value: Nullable<T>): Variant;
var
  v: TValue;
begin
  if value.HasValue then
  begin
    v := TValue.From<T>(value.Value);
    if v.IsType<Boolean> then
      Result := v.AsBoolean
    else
      Result := v.AsVariant;
  end
  else
    Result := Null; // Warum?
end;

[Dejan Vu]

'Null' ist einfacher zu handhaben als 'Unassigned'. Aber wissen tut das nur Meister Stevie.

[Nersgatt]

wenn du einen Variant mit dem Wert Null einem Integer oder einer Stringvariable zuweist, bekommst Du doch nicht 0, bzw. '' sondern eine Exception.
Für mich als Datenbankentwickler ist Null halt "leer". Unassigned kommt in meinen Gedankengängen nicht vor

Somit kann ich mit der Behandlung, wie es in Spring4D gelöst ist, sehr sehr gut leben. Ich hab (nach dem Vortrag von Stevie am Samstag) meine Anwendung von der Verwendung von Variants auf TNullable umgestellt. Das hat problemlos funktioniert und macht den Code deutlich schöner.

[Stevie]

Soweit ich weiß, ist Unassigned eher für OLE Zeugs - siehe auch Dokumentation, die da sagt:

Zitat:

Note: Unassigned is useful with variants referencing OLE Automation Objects that you want to keep "alive" until another value is assigned to the variant.

Und da der Typ Nullable<T> und nicht Unassignable<T> heißt, machts imho eher Sinn, Null zurückzuliefern, wenn der Nullable<T> leer ist.

Beim Hineingeben eines Variants sorgen sowohl Null als auch Unassigned (es wird mit VarIsNull or VarIsEmpty geprüft) dafür, dass es ein leerer Nullable<T> ist.
Allerdings muss sich beim herausgeben eines Variants für eins von beidem entschieden werden und da macht Null wie zuvor erwähnt eher Sinn.

Zitat von Der schöne Günther:

System.Variants.Null() liefert ein Variant, das bei seinen Casts immer "Null" zurückgibt. Auf eine Zahl ist es 0 , auf einen String ist es ein leerer String, auf eine Referenz ist es Nil usw.

Dementgegen steht System.Variants.Unassigned() : Das liefert einen Variant, der nichts ist. Man kann ihn nirgendwo hin casten, es steckt nichts drin.

Genau das Gegenteil ist der Fall, eine Zuweisung von Unassigned auf einen anderen Typ gibt immer den default Wert dieses Typs zurück (0, Leerstring, etc).
Bei Null gibts einen EVariantTypeCastError.

Zitat von Nersgatt:

Ich hab meine Anwendung von der Verwendung von Variants auf TNullable umgestellt. Das hat problemlos funktioniert und macht den Code deutlich schöner.

Das freut mich, dass es so gut geklappt hat.

[Dejan Vu]

Soweit ich mich erinnere, kann auf 'v = Null' geprüft werden ('v' ist ein Variant), aber auf 'v = Unassigned' nicht. Es ist also ein netter Nebeneffekt auch in Hinblick auf den Vergleich, das hier 'Null' geliefert wird.

[Stevie]

Zitat von Dejan Vu:

Soweit ich mich erinnere, kann auf 'v = Null' geprüft werden ('v' ist ein Variant), aber auf 'v = Unassigned' nicht. Es ist also ein netter Nebeneffekt auch in Hinblick auf den Vergleich, das hier 'Null' geliefert wird.

Doch geht beides, mit dem kleinen Haken, dass 0 = Unassigned true ist und sich Unassigned somit nicht als expliziter Zustand für "ist leer" benutzen lässt.

[Der schöne Günther]

Zitat von Stevie:

Genau das Gegenteil ist der Fall, eine Zuweisung von Unassigned auf einen anderen Typ gibt immer den default Wert dieses Typs zurück (0, Leerstring, etc).
Bei Null gibts einen EVariantTypeCastError.

Oh, stimmt, da habe ich mich vertan.

Mein Szenario war folgendes: Ich habe ein paar Variablen vom Typ Nullable<IrgendeinTyp> und muss die in einer TQuery in die Parameter (Data.DB.TParam ) stecken. Ein TParam hat eine Property Value vom Typ Variant . Der Setter dieser Property setzt die TParam-Eigenschaft Bound := VarIsClear(variantDings) . Bound gibt an, ob der Parameter gesetzt ist.

Ja, er ist gesetzt, und zwar auf NULL. Ich habe also, trotz anfänglicher Verwirrung, genau was ich will