Warum sind Klassenoperatoren nicht bissl intelligenter?

[himitsu]

Es geht ja noch weiter ... Delphi/Pascal kennt keine Unterscheidung zwischen Bitwise und Logical, bei and/or/xor, aber du kannst beides Deklarieren (für das komische BCPP),
was erstmal nicht schlimm ist, wenn dir der Compiler eine Meldung geben würde, dass er das Andere nicht verwendet.

Oder wenn du Equal deklariert hast, dann könnte man das für NotEqual mitverwenden, wenn dieses nicht Deklariert wurde.
Oder warum nicht gleich "eine" CompareMethode für Alles? mit den drei Ergebnissen -1, 0 und 1 anstatt 6 Methoden. CompareValue
Bzw. wenn etwas davon nicht deklariert wurde, dann könnte der Compiler mit 1 bis 2 Aufrufen alles Andere daraus generieren. (z.B. Equal und LessThan reicht aus, um alle Anderen zu emulieren)

Bei Add, And, Or und Xor ist die Reihenfolge der Parameter egal, also würde eine Variante reichen und der Compiler dreht die anderen Möglichkeiten einfach um.

Ich hatte mir auch ein class operator In(const LeftValue: TTestItem; const RightValue: array of Integer): Integer; deklariert, aber ist bei der Aufrufstelle was blöde.

Delphi-Quellcode:

// meldet mir out of Bonds, weil er das [] als Byte-Set interpretiert und erst dann die Typprüfung mit dem Ziel macht
if MyRec in [1000, 2000] then
// aber hier weiß er vom := , dass es ein IntegerArray werden soll, warum schaut er dann bei meinem Record nicht auch mal nach was er für Typen erwartet, schließlich wurde das vorher schon geparst
//Arr := [1000, 2000];

var Arr: TArray<Integer>;
if MyRec in Arr then // geht

[Dennis07]

Jo, das mag unlogisch erscheinen. Ich denke allerdings, dass es halt nunmal ist, wie der Compiler intern die Operatoren verwaltet. Das Problem ist nunmal, dass NotEqual halt nicht in jedem Fall not Equal entspricht.
Eine Ungleichheit (oder eine Gleicheit) stellt man bei manchen Typen halt unterschiedlich fest, und ein generischer Vergleich wäre ja da nochmal etwas anderes (und auch nicht auf jeden Typen anwendbar, beispiel:

Delphi-Quellcode:

type
  TMyPoint = record
    X, Y: Integer;
end;

Jetzt stell da mal eine sinnvolle Deklaration für einen Compare -Operator auf... Geht nicht. Dennoch wären Equal , NotEqual , GreaterThan , ... problemlos möglich.

[himitsu]

Klar kann man sowas machen, aber "logisch" ist es dann nicht, warum

if a = b then nicht das gleiche Ergebnis liefert, wie if not (a <> b) then .


Außer du fängst da mit einer Tristate-Logic oder mehr an
ungleich, fast gleich, gleich, gleicher, ganz gleich, identisch

OK, kennt man z.B. aus PHP
if (0 == '0') // true
if (0 == false) // true
und nicht
if (0 === '0') // false
if (0 === false) // false
aber auch da verhalten sich == und != gleich.