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

Delphi-Quellcode:

Nullable<Integer>

praktisch alles mögliche zuzuweisen. Das liegt daran, dass für ein Nullable eine implizite Operator-Überladung für

Delphi-Quellcode:

Variant

definiert ist:

Delphi-Quellcode:

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

Delphi-Quellcode:

Nullable<T>

und

Delphi-Quellcode:

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

Delphi-Quellcode:

NULL

-Wert dann korrekt zugewiesen wird.

Im Übrigen kann man eine Referenz durchaus einem

Delphi-Quellcode:

Integer

zuweisen ;)

Was nicht gehen sollte ist

Delphi-Quellcode:

var
  ni : Nullable<Integer>;

ni := 'Moin';

[Dejan Vu]

Delphi-Quellcode:

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:

Zitat von Der schöne Günther (Beitrag 1321424)

Kritik an Spring4D kann ich mir nicht erlauben

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

Zitat:

Zitat von Sir Rufo (Beitrag 1321443)

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

Delphi-Quellcode:

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

Delphi-Quellcode:

:= nil

ist natürlich viel komfortabler als irgendein Hickhack mit vielleicht

Delphi-Quellcode:

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

Delphi-Quellcode:

TField

-Objekten kompatibel zu machen? Wenn ja, dann wäre ein eigener Typ

Delphi-Quellcode:

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

Delphi-Quellcode:

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

Delphi-Quellcode:

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

Delphi-Quellcode:

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

Delphi-Quellcode:

Clear()

-Methode oder wie löscht man den?

[Stevie]

Zitat:

Zitat von Der schöne Günther (Beitrag 1321453)

Würdet ihr euch denn dazu überreden lassen der

Delphi-Quellcode:

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:

Zitat von Der schöne Günther (Beitrag 1321453)

Wenn die Pointer-Überladung rausfällt, bekommt ein Nullable dann eine

Delphi-Quellcode:

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

Delphi-Quellcode:

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...