operator overloading

[Socke]

Hallo,
ich habe einen ordinalen Typ mit begrenzter Größe. Aus einer Datenbank kann ich aber nur allgemeine Integer laden. Für den Fall, dass der Benutzer die Datenbank manipuliert hat, möchte ich beim Einlesen der Daten, den Wert automatisch "korrigieren" (d.h. auf den Wertebereich begrenzen). RangeChecking durch den Compiler hat den unangenehmen Seiteneffekt einer Exception (die ich gerne umgehen möchte) und beim operator overloading gibts nen Fehler:

Code: Alles auswählen

type
  TRating = 0..5;
operator := (i: Integer) r: TRating; // Error: Impossible operator overload
begin
  if i < low(TRating) then
    r := low(TRating) else
  if i > high(TRating) then
    r := high(TRating) else
    r := i;
end;

Habe ich das operator overloading vollkommen falsch verstanden und man kann nichts überladen, was eh schon da ist? Die Möglichkeit mit normalen Funktionsaufrufen möchte ich aus Gründen der Übersichtlichkeit eher ungern nutzen.

[knight]

Wäre es in deinem Fall nicht einfacher, wenn du das Feld bereits in der Datenbank auf den zulässigen Wertebereich begrenzt (CHECK Option)? Dann könntest du dir die Überprüfung beim Einlesen sparen.

knight

[Socke]

Wäre es in deinem Fall nicht einfacher, wenn du das Feld bereits in der Datenbank auf den zulässigen Wertebereich begrenzt (CHECK Option)? Dann könntest du dir die Überprüfung beim Einlesen sparen.

Versuch das mal SQLite zu erzählen. Da kannst du alles in allem abspeichern - egal welcher Datentyp oder welche Größe.
Mir fallen da nur gerade die trigger ein (on update/insert). Von denen habe ich aber so gut wie keine Ahnung. Deswegen wäre eine programmseitige Überprüfung am einfachsten.

[af0815]

Beim Operatoroverloading geht es um die Compilezeit, du kann das nicht auf die Laufzeit umwälzen. Somit bleibt dir kein Weg über, als es von Hand aus prüfen oder es der DB machen zu lassen.

[Socke]

Beim Operatoroverloading geht es um die Compilezeit, du kann das nicht auf die Laufzeit umwälzen. Somit bleibt dir kein Weg über, als es von Hand aus prüfen oder es der DB machen zu lassen.

Soweit ich das verstanden habe, werden Operatoren, die auf Nicht-Konstanten angewendet werden die Ergebnisse immer erst zur Laufzeit ausgewertet. Selbstverständlich muss ein Operator schon zur Laufzeit definiert sein, aber ich hatte gedacht, dass der Compiler in der Compilezeit immer dann diesen Operator einfügt, wenn er in der Laufzeit aufgerufen werden würde (bzw. entsprechend Funktionsaufrufe auf eine Operator-Funktion). Sollte ich hier ein massives Missverständnis des Konzeptes haben, bitte ich darum mich aufzuklären.

Von Hand zu prüfen, hieße jedes Mal explizit eine bestimmte Funktion aufzurufen. Dies hätte ich gerne implizit erledigt.
Hast du ein Beispiel, wie man das DB-seitig umsetzen kann (SQL), zur Hand?

[lrlr]

warum es nicht funktioniert, weiß ich nicht, weil ich operator overloading noch nie betrieben habe..

verwend doch mal
type
TRating = Integer;

vielleicht gehts ..

(weil die 0..5 mit deinem operator overloading eh keine "nutzen" mehr hat..)

die "lösung" Ansicht ist aber sowieso nicht schöne (meine meinung)

1. der user sollte mitgeteilt bekommen, dass er etwas falsch gemacht hat (eingabe von 7 z.b.) und nicht einfach ungefragt und versteckt auf 5 ändern..

2. SO kannst zu keine Abhängigkeiten prüfen (z.b. dass 5 nur zulässig ist, wenn man auch das Feld "Grund für Bewertung 5" ausgefüllt hat)


Möglichkeiten: gibts wohl wie Sand am Meer, welche jetzt die "beste" ist, hängt von (zu) vielen Faktoren ab ...
und oft auch eine "glaubensfrage"..
BusinessObjects, (incl ORM) usw. macht man z.b. oft.,

wenn man direkt mit einer datenbank (die man auch nicht vorhat auszutauschen) arbeitet, kann man wohl auch trigger verwenden, für "low level" überprüfungen

[af0815]

In der unit math ist folgendes

Code: Alles auswählen

function EnsureRange(const AValue, AMin, AMax: Integer): Integer

damit kannst du den Bereich eingrenzen (so wie es im ersten Post ist). Ist dann halt eine FPC-RTL Funktion.

[Socke]

1. der user sollte mitgeteilt bekommen, dass er etwas falsch gemacht hat (eingabe von 7 z.b.) und nicht einfach ungefragt und versteckt auf 5 ändern..

2. SO kannst zu keine Abhängigkeiten prüfen (z.b. dass 5 nur zulässig ist, wenn man auch das Feld "Grund für Bewertung 5" ausgefüllt hat)

Im Prinzip hast du Recht; In dem Falle sollte die Überprüfung aber vor der Zuweisung und nicht erst bei der Zuweisung geschehen, da dann in der Zuweisung eine Exception ausgelöst werden müsste, damit das dann noch ggf. geändert werden kann

In meinem konkretem Fall solls aber nur ein kleines Control zum Anklicken (0-5 Punkte) geben. Da intern keine anderen Werte als 0-5 gebraucht werden, wäre diese Funktion mehr oder weniger nur beim Einlesen im Einsatz.

In der unit math ist folgendes

Code: Alles auswählen

function EnsureRange(const AValue, AMin, AMax: Integer): Integer

damit kannst du den Bereich eingrenzen (so wie es im ersten Post ist). Ist dann halt eine FPC-RTL Funktion.

Diese Funktion kannte ich bisher noch nicht. Da ich die jetzt aber nicht mehr brauche (habe meine eigene Funktion geschrieben), könnte ich diese jetzt höchsten Kapseln damit ich nicht immer die entsprechenden Werte angeben muss.