Operator Overloading for CLASSES (not records!)

[Codehunter]

Zitat von himitsu:

Zitat von Codehunter:

Genau genommen sind Records auch Klassen.

In Delphi ist es andersrum.
Klassen sind intern ein Record mit einem Pointer davor. (und der Pointer zeigt in die Mitte des Records, statt auf dessen Anfang)

Um mal meinen Vater zu zitieren: "Alles ein Gemehr"

Was mich an der Sache hier viel mehr interessiert hat waren überladene Operatoren in Record Helpers. Das wäre wirklich eine nützliche Sache. Denn damit könnte man das Standardverhalten für einfache Typen lokal übersteuern. Beispiel:

Delphi-Quellcode:

var
  S: string;
begin
  S := 'foo';
  if S in ['foo', 'bar'] then begin
    {...}
  end;
end;

das wäre doch viel übersichtlicher als komplexe if-or-or-or-then-Konstrukte. Noch besser wäre natürlich, wenn case auch mit Strings umgehen könnte:

Delphi-Quellcode:

var
  S: string;
begin
  S := 'foo';
  case S of
    'foo': {...}
    'bar': {...}
  end;
end;

Für case-Anweisungen fehlt irgendwie ein überladbarer Operator. Equality spielt da zwar mit rein, aber case an sich ist nicht flexibel genug. Da ist switch-case in anderen Sprachen (z.B. Javascript, PHP) deutlich komfortabler.

[freimatz]

Ich bin froh, dass das nicht geht. Das verhindert damit oft unsauberen Code. (Wegen SoC https://en.wikipedia.org/wiki/Separation_of_concerns)

[Codehunter]

Zitat von freimatz:

Ich bin froh, dass das nicht geht. Das verhindert damit oft unsauberen Code. (Wegen SoC https://en.wikipedia.org/wiki/Separation_of_concerns)

Nach deiner Logik wäre ja die "Quelltextsauberkeit" umgekehrt äquivalent zur Anzahl verfügbarer Sprachfeatures

[freimatz]

Zitat von Codehunter:

Zitat von freimatz:

Ich bin froh, dass das nicht geht. Das verhindert damit oft unsauberen Code. (Wegen SoC https://en.wikipedia.org/wiki/Separation_of_concerns)

Nach deiner Logik wäre ja die "Quelltextsauberkeit" umgekehrt äquivalent zur Anzahl verfügbarer Sprachfeatures

Nein. Nach meiner Logik steht "das" steht für ein Sprachfeature und genau das erwähnte.

[himitsu]

Nativ fehlt halt so Einiges in Delphi, was man schonmal gebraucht hätte. (Einiges gibt es zum Glück von Fremdanbietern, was aber auch schnell den Gesamtpreis von Delphi etwas in die Höhe treibt)

DefaultPropery für Strings (das mit dem Default-Attritut ist schon blöd, denn Eines steht davor und das Andere dahinter und wenn ich jetzt frage wer von euch überhaupt weiß dass es sowas gibt, dann hebt bestimmt kaum jemand die Hand), Attribute hinter dem was man beschreiben will (statt davor/drüber), kleine Makros, assoziative Arrays, ein besseres CASE, ...

Nicht schön, aber was soll's.

Delphi-Quellcode:

case IndexStr(S, ['A', 'B', 'C']) of
  0{A}: ...;
  1{B}: ...;
  2{C}: ...;
end;

type TX = (A, B, C);
//case TX(IndexStr(S, ['A', 'B', 'C'])) of
case TX(GetEnumValue(TypeInfo(TX), S)) of 
  A: ...;
  B: ...;
  C: ...;
end;

[Codehunter]

Zitat von himitsu:

assoziative Arrays

Also diesbzgl. bin ich mit TDictionary doch recht zufrieden.

[Uwe Raabe]

Zitat von himitsu:

wenn ich jetzt frage wer von euch überhaupt weiß dass es sowas gibt, dann hebt bestimmt kaum jemand die Hand

[Rollo62]

und danke für die Erinnerung das es sowas gibt ...

[Stevie]

Zitat von Codehunter:

Was mich an der Sache hier viel mehr interessiert hat waren überladene Operatoren in Record Helpers. Das wäre wirklich eine nützliche Sache. Denn damit könnte man das Standardverhalten für einfache Typen lokal übersteuern.

Das geht wie gesagt nur bei Typen, denen man sowieso Operatoren verpassen kann, wie Records oder Klassen (bei Klassen mit der schon besprochenen Einschränkung). Nicht aber bei string, Integer und Co. Ich hab z.B. weitere Operatoren für System.Rtti.TValue geschrieben, die Anwendung finden, wenn ich die entsprechende Unit einbinde.

Zitat von Codehunter:

Für case-Anweisungen fehlt irgendwie ein überladbarer Operator. Equality spielt da zwar mit rein, aber case an sich ist nicht flexibel genug. Da ist switch-case in anderen Sprachen (z.B. Javascript, PHP) deutlich komfortabler.

Die unterstützung von nicht ordinalen Typen in einem switch/case hat aber in den mir bekannten Sprachen nichts mit Operatoren auf den unterstützten Typen zu tun sondern sind in der Sprachsyntax bzw dem Compiler verankert, der dann weiß, wie er damit umzugehen hat. Bei Ordinaltypen kann eine Jumptable auf den passenden Wert gebaut werden, so macht Delphi das, aber bei anderen Typen müssen andere Strategien her, die in aller Regel der Compiler entscheidet (wie z.B. in C# bei string). Kommen dann noch so interessante Dinge wie Pattern matching hinzu, wirds komplexer.

Bzgl Verbesserung des case of Statements: einfach mal nen Vote für RSP-16478 abgeben und die Daumen drücken.