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

[Stevie]

Zitat:

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

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

Ja, das ist zugegebenerweise ziemlich bescheiden so, da hier der string erst in einen Variant konvertiert wird, um dann in den Implicit operator gepackt zu werden... :wall:
Wir machen uns mal Gedanken dazu :gruebel:

Eine Möglichkeit, die mir spontan einfällt, wäre den implicit operator für Variant->Nullable<T> auf explicit zu ändern. Dann muss man einen Hardcast schreiben:

Delphi-Quellcode:

myNullableInteger := 'Wurst'; // kompiliert nicht
myNullableInteger := Nullable<Integer>('Wurst'); // kompiliert aber wie gehabt Exception
myNullableInteger := myVariant; // kompiliert nicht mehr - breaking change (*)
myNullableInteger := Nullable<Integer>(myVariant); // kompiliert und wie bisher je nachdem, was im Variant drin steckt erfolgreich oder Exception

P.S. Näää, vergisset, dat geht nich -.- Dann würde bei (*) wieder die Variant to T konvertierung zuschlagen und möglicherweise strings in Integer casten und die in den Nullable packen oder EVariantTypeCastError werfen, wenn null drin steckt. :(

[Sir Rufo]

Ich habe in meiner Bibliothek auch einen Nullable-Typen und da gibt es zusätzlich einen

Delphi-Quellcode:

type
  Nullable = record
    const NULL : Nullable;
  end;

type
  Nullable<T> = record
  public
    class operator implicit( const Value : Nullable ): Nullable<T>;
  end;

Dafür habe ich zwar keine Variants-Unterstützung, aber immer eine Typsichere Zuweisung :stupid:

Hübsch finde ich es auch noch

Delphi-Quellcode:

var
  ni : Nullable<Integer>;
begin
  ni := 5;
  ni := Nullable.Null;

  // auf NULL prüfen
  if ni = Nullable.Null then
  begin
  end;
  // auf NULL prüfen
  if not ni.HasValue then
  begin
  end; 
  
end;

Hübsch fand ich auch noch die Abkürzungen (damit meine zarten Finger geschont werden :mrgreen:)

Delphi-Quellcode:

NullableInteger = Nullable<Integer>;
NInteger = NullableInteger;

[Stevie]

Zitat:

Zitat von Sir Rufo (Beitrag 1321469)

Dafür habe ich zwar keine Variants-Unterstützung, aber immer eine Typsichere Zuweisung :stupid:

Najo, einen Variant nem Nullable<Integer> zuweisen, der nicht in einen Integer konvertiert werden kann, knallt bei dir leider ebenfalls zur Laufzeit.

Zitat:

Zitat von Sir Rufo (Beitrag 1321469)

Hübsch fand ich auch noch die Abkürzungen (damit meine zarten Finger geschont werden :mrgreen:)

Simples Aliasing, das kann ja auch jeder mit den Spring4D Nullables machen, wie er beliebt.

[Sir Rufo]

Zitat:

Zitat von Stevie (Beitrag 1321470)

Zitat:

Zitat von Sir Rufo (Beitrag 1321469)

Dafür habe ich zwar keine Variants-Unterstützung, aber immer eine Typsichere Zuweisung :stupid:

Najo, einen Variant nem Nullable<Integer> zuweisen, der nicht in einen Integer konvertiert werden kann, knallt bei dir leider ebenfalls zur Laufzeit.

Das ist aber ein Verhalten, was auch ohne den Nullable Typen auftritt ... ich verbessere nichts, verschlechtere aber auch nichts ;)

Zitat:

Zitat von Stevie (Beitrag 1321470)

Zitat:

Zitat von Sir Rufo (Beitrag 1321469)

Hübsch fand ich auch noch die Abkürzungen (damit meine zarten Finger geschont werden :mrgreen:)

Simples Aliasing, das kann ja auch jeder mit den Spring4D Nullables machen, wie er beliebt.

Die Menschen/Programmierer sind doch faul (ich zumindesntens) ;)

[HeZa]

Zitat:

Zitat von Sir Rufo (Beitrag 1321429)

Weil du dann aus einer Datenbank die Werte direkt zuweisen kannst und ein

Delphi-Quellcode:

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
  Delphi-Quellcode:

  TDataSet

  mit
  Delphi-Quellcode:

  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

Delphi-Quellcode:

myNullableInt := myDatabaseField.Value

oder

Delphi-Quellcode:

myNullableInt := myStrangeVariant

Ich kann allerdings nicht mehr sagen

Delphi-Quellcode:

myNullableInt := myFloatValue

[Dejan Vu]

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

[Sir Rufo]

Zitat:

Zitat von Dejan Vu (Beitrag 1321545)

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

Ein

Delphi-Quellcode:

Nullable<T>

soll eben nicht alles beinhalten, sondern typsicher einen Wert vom Typ

Delphi-Quellcode:

T

oder eben nichts.

[Stevie]

Zitat:

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

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

Delphi-Quellcode:

myNullableInt := myDatabaseField.Value

oder

Delphi-Quellcode:

myNullableInt := myStrangeVariant

Ich kann allerdings nicht mehr sagen

Delphi-Quellcode:

myNullableInt := myFloatValue

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

Also so:

Delphi-Quellcode:

myNullableInt := Nullable<Integer>(myDatabaseField.Value);

oder

Delphi-Quellcode:

myNullableInt := Nullable<Integer>(myStrangeVariant)

[Dejan Vu]

Zitat:

Zitat von Sir Rufo (Beitrag 1321550)

Ein

Delphi-Quellcode:

Nullable<T>

soll eben nicht alles beinhalten, sondern typsicher einen Wert vom Typ

Delphi-Quellcode:

T

oder eben nichts.

Ach so. Und es geht darum, das man einem typsicheren

Delphi-Quellcode:

Nullable<Integer>

auch einen String zuweisen kann, ohne das es knallt (also eher 'ein bisschen typsicher'). Und das der Wert dann 0 ist.

Na ja. Ein etwas besseres 'VarToInt' (aka convert) tut's ja auch. Also: Ich weise einem Variant zu, was ich will und erst beim Auslesen interpretiere ich, was da drin steht. Hmm. Vom Verhalten sehe ich jetzt nicht so den Unterschied zu normalen Variants, aber egal.

[Der schöne Günther]

Zitat:

Zitat von Stevie (Beitrag 1321558)

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

Hardcast, oder gleich den passenden Typen reinstecken. Also

Delphi-Quellcode:

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.

[Stevie]

TField.Value ist ein Variant. Und wenn man AsX (X sei der Typ des Felds, also string, Integer o.Ä.) führt bei Null zu einem Fehler. Daher gibts den Overload für Variant, so dass der Variant nicht erst in eine Null exception läuft sondern das "auspacken" dem Nullable überlässt.

Und nein, ein Nullable ist kein Variant! In einen Variant kann ich zur Laufzeit alles (*) reinpacken und der Variant ist fröhlich. In einen Nullable geht nur T oder ein Variant (wobei der Variant auch nur einen T beinhalten darf, es wird hier keine Konvertierung durchgeführt). Dass das nunmal nicht zur Compiletime geht liegt daran, dass es nicht im Compiler eingebaut ist. Dafür musst du dich an Embarcadero wenden.

(*) was in einen Variant passt

Wenn du in deinem Code die stellen aufdecken willst, die den Variant overload nutzen, dann schlag ich vor, pack nen deprecated an diesen Overload und du siehst beim Kompilieren jede Stelle, die den nutzt.

[Sir Rufo]

Zitat:

Zitat von Dejan Vu (Beitrag 1321568)

Zitat:

Zitat von Sir Rufo (Beitrag 1321550)

Ein

Delphi-Quellcode:

Nullable<T>

soll eben nicht alles beinhalten, sondern typsicher einen Wert vom Typ

Delphi-Quellcode:

T

oder eben nichts.

Ach so. Und es geht darum, das man einem typsicheren

Delphi-Quellcode:

Nullable<Integer>

auch einen String zuweisen kann, ohne das es knallt (also eher 'ein bisschen typsicher'). Und das der Wert dann 0 ist.

Na ja. Ein etwas besseres 'VarToInt' (aka convert) tut's ja auch. Also: Ich weise einem Variant zu, was ich will und erst beim Auslesen interpretiere ich, was da drin steht. Hmm. Vom Verhalten sehe ich jetzt nicht so den Unterschied zu normalen Variants, aber egal.

Nach meinem Verständnis (und auch meiner Implementierung) kann einem

Delphi-Quellcode:

Nullable<Integer>

eben kein

Delphi-Quellcode:

string

zugewiesen werden. Mein

Delphi-Quellcode:

Nullable<T>

hat auch keinen impliziten Cast von einem

Delphi-Quellcode:

Variant

, denn nach meinem Verständnis soll ein

Delphi-Quellcode:

Nullable<T>

eben nicht alles beinhalten, sondern typsicher den angegebenen Typen

Delphi-Quellcode:

T

oder eben nichts.

Genau das steht auch schon in meinen Beiträgen hier ...

Und wie immer ist dieses Konstrukt einfach nur zum Vereinfachen gedacht:

Delphi-Quellcode:

var
  a,b,c : Nullable<Integer>;
  d : Integer;
begin
  a := Nullable.Null;
  b := 42;
  c := a+b; // c => Null
  d := a.ValueOrDefault() + b.ValueOrDefault(); // d => 42
end;

[Stevie]

Dann mach doch deinen Nullable open Source, Günther kann ihn nutzen und wir ersparen uns die ewige Im-Kreis-Dreherei. :roll:

P.S. Was macht eigtl dein Add overload bei Typen, bei denen es keine Addition gibt?

[Der schöne Günther]

Lass uns noch ein bisschen drehen :spin2:
Ein bisschen.

Zitat:

Zitat von Stevie (Beitrag 1321574)

Daher gibts den Overload für Variant, so dass der Variant nicht erst in eine Null exception läuft sondern das "auspacken" dem Nullable überlässt.

Das sehe ich ja voll und ganz ein. Nur nicht, warum es implizit sein muss.

Ist es explizit, kann man weiterhin alle

Delphi-Quellcode:

TField.Value

reinstecken. Oder

Delphi-Quellcode:

IXMLNode.Value

. Oder was auch immer. Was würde man dadurch verlieren?

[Sir Rufo]

Zitat:

Zitat von Stevie (Beitrag 1321576)

P.S. Was macht eigtl dein Add overload bei Typen, bei denen es keine Addition gibt?

Das war einfach nur Wunschdenken und ich wollte auch mal komische Sachen schreiben. Liegt wohl am Wetter :stupid:

[Stevie]

Zitat:

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

Lass uns noch ein bisschen drehen :spin2:
Ein bisschen.

Zitat:

Zitat von Stevie (Beitrag 1321574)

Daher gibts den Overload für Variant, so dass der Variant nicht erst in eine Null exception läuft sondern das "auspacken" dem Nullable überlässt.

Das sehe ich ja voll und ganz ein. Nur nicht, warum es implizit sein muss.

Ist es explizit, kann man weiterhin alle

Delphi-Quellcode:

TField.Value

reinstecken. Oder

Delphi-Quellcode:

IXMLNode.Value

. Oder was auch immer. Was würde man dadurch verlieren?

Guck dir einfach die Doku zu implicit und explicit Operator overloads an denn du scheinst offensichtlich miszuverstehen, was implizit und explicit bedeutet.
Der Fakt, dass ein string in einen Variant gecastet wird und dann an den Variant Overload übergeben wird, hat nix mit dem Overload zu tun, sondern damit, wie Variants funktionieren.

Zitat:

Zitat von Sir Rufo (Beitrag 1321578)

Zitat:

Zitat von Stevie (Beitrag 1321576)

P.S. Was macht eigtl dein Add overload bei Typen, bei denen es keine Addition gibt?

Das war einfach nur Wunschdenken und ich wollte auch mal komische Sachen schreiben. Liegt wohl am Wetter :stupid:

Schade, dachte du hättest da einen Trick gefunden. Bei einem im Compiler eingebauten nullable werden die ja die Operatoren des parameter Typs ge"lifted".

[Dejan Vu]

Zitat:

Zitat von Sir Rufo (Beitrag 1321575)

meinem ... meiner ... Mein ... meinem ... meinen

Laut Titel geht es um Spring4D: Nullables. :roll:

Seitdem ich Nullables in C# entdeckt habe, trauere ich den Variants hinterher. Auf der anderen Seite brauche ich sie eigentlich nie.

[Sir Rufo]

Zitat:

Zitat von Dejan Vu (Beitrag 1321617)

Zitat:

Zitat von Sir Rufo (Beitrag 1321575)

meinem ... meiner ... Mein ... meinem ... meinen

Laut Titel geht es um Spring4D: Nullables. :roll:

Jupp, und dem aufmerksamen Leser ist auch nicht entgangen, das wir - wenigstens der größte Teil - hier über Sinn und Zweck der ein oder anderen Teile des Spring.Nullable diskutieren und Stevie schon seine Bereitschaft zur Überarbeitung des Spring.Nullable mitgeteilt hat.

Wenn einem die eine oder andere Funktionalität nicht zusagt, dann kommentiert man die einfach aus (Open Source lässt grüßen).

Mein Beitrag hierzu war den Grund zu erläutern, warum es so einen Variant Cast gibt - ich persönlich den aber nicht mag - und wie ich es bei mir persönlich gelöst habe, um eine Alternative aufzuzeigen.

Das nennt man dann Austausch von Gedanken und Erfahrungen. Mag seltsam klingen, mir aber egal.

[Dejan Vu]

Sag mal, hast Du Anteile an Bold-Schriften erworben oder wieso spickst Du deine Ausführungen ständig damit?

Das fette 'Mein..Meine...meins' Zitat sollte eher darauf hinweisen, das man es mit der Betonung der EIGENEN Meinung auch ÜBERTREIBEN kann, ABER DAS SCHEINT NICHT ANGEKOMMEN ZU SEIN !!!!!11!!!!11!1!EINS!!!1!!ELF!!!

Wink. Zaun. Pfahl. Netiquette. Blinzel. Knick-Knack. Say No more.

[Stevie]

Lange hat's gedauert, aber ich hab wohl endlich eine Lösung gefunden ;)

[Der schöne Günther]

Lange hatte ich es auf meiner "Demnächst lesen"-Liste, jetzt gelesen und ich musste lachen :-D

Coole Idee :thumb: