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;

[Stevie]

Zitat von Der schöne Günther:

Kritik an Spring4D kann ich mir nicht erlauben

Wieso nicht? Wenn sie konstruktiv ist, ist das immer willkommen.

Zitat von 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;

Ja, damit man meinNullable := nil schreiben kann.

Über die Nützlichkeit und die möglichen Auswirkungen davon kann man gerne diskutieren.
Aber wenn man das nicht mag, auskommentieren, glücklich sein. Das ist ja das schöne an open Source, gell?

[Der schöne Günther]

Klar, das mit dem := nil ist natürlich viel komfortabler als irgendein Hickhack mit vielleicht TNullable<Integer>.Empty oder sowas.

Aber mit dem Variant-Gedöns kann ich mich wirklich nicht anfreunden. Die ganze Typsicherheit geht einem doch da den Bach runter. War die Intention denn von Anfang an, das mit TField -Objekten kompatibel zu machen? Wenn ja, dann wäre ein eigener Typ TFieldContent<T> oder sowas besser.

Auskommentieren und Spring neu kompilieren habe ich mich noch nicht getraut, ich hätte spontan erwartet dass Spring die Nullables dann selbst irgendwo so benutzt und ihm diese Operator-Überladung dann fehlt...

[Stevie]

Dein eingangs beschriebenes Problem liegt einzig und allein an dem Pointer overload, den ich aber in Rücksprache mit meinem Kollegen für 1.2 entfernen werde.
Immerhin kann man ja := Null schreiben, was exakt dieselbe Auswirkung hat, nur ohne die negativen Seiteneffekte, dass ich sämtliche Referenztypes assignen kann.

Nullable<T> <-> Variant Kompatibilität ist explizites Feature.

Allerdings werden auch nur Variants akzeptiert, die direkt den zu T passenden Typen haben.
Das hier geht also nicht: myIntNullable := '5'; Kompiliert zwar (sorry!) aber wirft zur Laufzeit ein EInvalidCast.

[Der schöne Günther]

Würdet ihr euch denn dazu überreden lassen der Value -Property dann einen Setter zu verpassen damit man, wenn man will, zur Compile-Zeit ein bisschen Typsicherheit hat?

Wenn die Pointer-Überladung rausfällt, bekommt ein Nullable dann eine Clear() -Methode oder wie löscht man den?

[Stevie]

Zitat von Der schöne Günther:

Würdet ihr euch denn dazu überreden lassen der Value -Property dann einen Setter zu verpassen damit man, wenn man will, zur Compile-Zeit ein bisschen Typsicherheit hat?

Absolut nicht. Nullable<T> ist als immutable designed.

Überleg mal, was sonst mit solchem Code passiert:

Delphi-Quellcode:

myObj.NullableIntProp.Value := 42;
...

Da Nullable<T> ein Record ist, würdest du nämlich dann nur die lokale Kopie verändern.
siehe http://stackoverflow.com/a/9157045/587106

Zitat von Der schöne Günther:

Wenn die Pointer-Überladung rausfällt, bekommt ein Nullable dann eine Clear() -Methode oder wie löscht man den?

Kein Clear, selbe Argumentation wie zuvor.

Delphi-Quellcode:

x := Null;
...

Außerdem könnte man sonst eine readonly nullable Eigenschaft nicht vor Modifikation schützen können.

[Der schöne Günther]

Bitter, da habe ich auf die Schnelle nicht dran gedacht.

Trotzdem macht mir myNullableInteger := 'Wurst' Angst. Ist mir neulich zum ersten mal zur Laufzeit um die Ohren geflogen und jetzt frage ich mich die ganze Zeit wie ich noch solche Stellen finden kann...