Spring4D: Nullables

[Der schöne Günther]

Eine Verständnisfrage zu Nullable<T> in Spring4D:

Delphi-Quellcode:

procedure test();
var
   numberValue: Spring.Nullable<Integer>;
begin
   numberValue := 99.0; 
   numberValue := TObject.Create();
end;

Der Compiler hat nichts dagegen, einem Nullable<Integer> praktisch alles mögliche zuzuweisen. Das liegt daran, dass für ein Nullable eine implizite Operator-Überladung für Variant definiert ist:

class operator Implicit(const value: Variant): Nullable<T>;


Kritik an Spring4D kann ich mir nicht erlauben, aber ich finde das schrecklich. Warum sollte man so etwas wollen? Zwischen Nullable<T> und T hin und her ist klar, aber warum Variant zu Nullable<T> generell erlauben?

[Sir Rufo]

Weil du dann aus einer Datenbank die Werte direkt zuweisen kannst und ein NULL -Wert dann korrekt zugewiesen wird.

Im Übrigen kann man eine Referenz durchaus einem Integer zuweisen

Was nicht gehen sollte ist

Delphi-Quellcode:

var
  ni : Nullable<Integer>;

ni := 'Moin';

[Dejan Vu]

ni := TObject.Create() sollte aber auch nicht gehen.

[Sir Rufo]

Gerade mal eben geschaut, es liegt nicht an den Variants, sondern an

Delphi-Quellcode:

type
  Nullable<T> = record
    // ...
    class operator Implicit(value: Pointer): Nullable<T>; // Übeltäter
    // ...
  end;

[HeZa]

Zitat von Sir Rufo:

Weil du dann aus einer Datenbank die Werte direkt zuweisen kannst und ein NULL -Wert dann korrekt zugewiesen wird.

Den Wunsch nach einer einfachen Zuweisung für ein Datenbank-Feld kann ich nachvollziehen. Dafür aber die Typ-Sicherheit beim Kompilieren aufzugeben wäre mir ein zu hoher Preis.

Mein Vorschlag

• Implizite Variant Zuweisung aus Spring.Nullable<T> entfernen
• Helper-Klasse für TDataSet mit AsNullable<T>

Dann könnte man schreiben

Delphi-Quellcode:

var
  myNullableInt: Spring.Nullable<T>
...
  myNullableInt := myQuery.FieldByName('MY_FELD').AsNullable<Integer>;
  // alternative Syntax
  myNullableInt := myQuery.NullableField<Integer>('MY_FELD');

[Der schöne Günther]

Ich verstehe eins hierbei noch nicht:

Warum ist denn die Variant-Geschichte eigentlich Implicit und nicht Explicit?

Wäre Sie es, kann ich immer noch sagen
myNullableInt := myDatabaseField.Value oder
myNullableInt := myStrangeVariant

Ich kann allerdings nicht mehr sagen
myNullableInt := myFloatValue

[Dejan Vu]

Wenn also Nullables beliebigen Typs sein können, wieso verwende ich nicht dann einfach Variants?

[Sir Rufo]

Zitat von Dejan Vu:

Wenn also Nullables beliebigen Typs sein können, wieso verwende ich nicht dann einfach Variants?

Ein Nullable<T> soll eben nicht alles beinhalten, sondern typsicher einen Wert vom Typ T oder eben nichts.

[Stevie]

Zitat von Der schöne Günther:

Ich verstehe eins hierbei noch nicht:

Warum ist denn die Variant-Geschichte eigentlich Implicit und nicht Explicit?

Wäre Sie es, kann ich immer noch sagen
myNullableInt := myDatabaseField.Value oder
myNullableInt := myStrangeVariant

Ich kann allerdings nicht mehr sagen
myNullableInt := myFloatValue

Nö, implicit heißt normale Zuweisung, explicit heißt, dass man einen Hardcast nutzen muss.

Also so:
myNullableInt := Nullable<Integer>(myDatabaseField.Value); oder
myNullableInt := Nullable<Integer>(myStrangeVariant)

[Der schöne Günther]

Zitat von Stevie:

Nö, implicit heißt normale Zuweisung, explicit heißt, dass man einen Hardcast nutzen muss.

Hardcast, oder gleich den passenden Typen reinstecken. Also myDatabaseField.Value . Das will man im Endeffekt doch.

Oder ist es tatsächlich, wie Dejan Vu meint, nur als eine andere Schreibweise für Variants gedacht?

Delphi-Quellcode:

      class operator Explicit(const from: Variant): Nullable<T>;
      class operator Implicit(const from: T): Nullable<T>;

erlaubt:

Delphi-Quellcode:

var
   myWrapper: TWrapper<Integer>;
   myVariant: Variant;
begin
   myWrapper := 42;

   //myWrapper := 'Hallo'; // nope

   myWrapper := Variant('Hallo');
   // oder
   myVariant := 'Hallo';
   myWrapper := myVariant;
end.