Spring4D: Nullables

[Stevie]

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

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...
Wir machen uns mal Gedanken dazu

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

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 )

Delphi-Quellcode:

NullableInteger = Nullable<Integer>;
NInteger = NullableInteger;

[Stevie]

Zitat von Sir Rufo:

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

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

Zitat von Sir Rufo:

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

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

[Sir Rufo]

Zitat von Stevie:

Zitat von Sir Rufo:

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

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 von Stevie:

Zitat von Sir Rufo:

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

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

[Dejan Vu]

Zitat von Sir Rufo:

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

Ach so. Und es geht darum, das man einem typsicheren 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.