TCaption = type String

[Rollo62]

Hallo zusammen,

es gibt hier eine interessante Zusammenstelung von J.Pluimers, zu dem Unterschied zwischen

Delphi-Quellcode:

type
    TCaption = type string;

und

Delphi-Quellcode:

type
    TCaption = string;

Oder verstehe ich das falsch, und es ist doch Letzteres ?

War vielleicht mal in älteren Delphi's so,
aber warum hat man dann dafür eigentlich Ersteres gewählt, und nicht das zweite, was mehr kompatibel wäre ?
Hat das wohl einen bestimmten Grund den ich nicht sehe, oder ist das nur ein "Typo".

Ich bin generell auf "Typenreduzierung" aus, nicht so sehr wie in JS,
aber zumindest so das nicht jeder triviale Typ auch noch separiert wird.
Das erleichtert für mich den Austausch zwischen Komponenten erheblich.

[Bernhard Geyer]

Diese Definition ist schon seit "Urzeiten" von Delphi so.
Ob es noch jemand bei Emba gibt der das Weiß ist mehr als fraglich.

Evtl. war initial mal angedacht das die Zeichenmenge in Captions reduziert ist um z.B. Steuerzeichen zu verbieten.
Hat sich halt überlebt und keiner wollte hier durch Änderung "Codebreaks" provozieren.

[Rollo62]

Aha, dankesehr.
Zeichenmenge, Stringlänge, oder sonstige Zeichensatz-Beschränkungen wäre eine Erklärung.
Wobei man dann doch nur den Typ als "Hinweis" hat, die eigentliche Beschränkungen muss man aussenrum machen,

[himitsu]

Jupp, da bin ich auch schon drauf reingefallen.

Im Prinzip ist war soeine Typisierung nicht schlecht, wären da nun nicht die RecordHelper.
Das ist aber nicht der Fehler dieser Typen, sondern dass diese Helperdrecksdinger keine Vererbung kennen und somit hängen sie ausschließlich an "string" hängen.


Gut, warum TCaption so abgeleitet ist, dafür fällt mir kein Grund ein, aber z.B. für TFilename gäbe es da nun interessante Möglichkeiten, dort "auch" die Dateinamensbehandlungen, wie z.B. Exists, ExtractFilename, ExpandEnvironmentVariable, usw. dranzuhängen. (nur darauf war in den letzten Jahren bei Emba auch noch niemand gekommen, selbst wenn man es denen sagte)

[edit]
Wobei, eine Sache fällt mir grade noch für die Captions ein, das Ampersand.
StripHotkey, GetHotkey und SameCaption im Helper, inkl. der Vergleichs-Operatoren.

[Rollo62]

Zitat von himitsu:

Im Prinzip ist war soweine Typisierung nicht schlecht...

interessante Möglichkeiten, dort "auch" die Dateinamensbehandlungen, wie z.B. Exists, ExtractFilename, ExpandEnvironmentVariable, usw. dranzuhängen ...

Ic bin mehr der Verfechter von reinen Typen, denn das "dranhängen" kann nie vollständig oder richtig sein.
Für die ein Anwendung passts, für die Andere nicht.

Deshalb besser "String" statt zu versuchen zuviel Brimborium drumrum zu bauen.

Wer das will könnte ja besser einen Record nehmen, und sich das was fehlt drumrum bauen (kommt jetzt wohl in die Gänge mit den Custom Managed Records).

RecordHelper-Vererbung wäre wirklich schön, aber weil die reinen Typen auch keine Pointer sind
ist das wohl schwieriger, aber wohl nicht total unlösbar für einen cleveren Compiler.

[himitsu]

Nja, Record-Methoden und Helper erleichtern einem über die Codevervolständigung (wenn sie denn funktioniert) das Leben ungemein.

Wenn man einen Caption- oder Filename-Typen hat und über Variable. angezeigt bekommt was es da alles für Funktionen gibt.

Managed Records: Hey, die sollten letztes Jahr auch schonmal kommen ... ob es diemal wirklich klappt? (hab ja schon fast 10 Jahre drauf gewartet, als ich denen damals schon den fast fertigen Code-Vorschlag im CC übergab)
https://blog.marcocantu.com/blog/201...ds-delphi.html
https://blog.marcocantu.com/blog/201...erring-managed records.html
Und mit ARC im Windows wird das dann voll der Spaß.

[Rollo62]

Zitat von himitsu:

erleichtern einem über die Codevervolständigung ...

Aha, noch mehr was funktionieren könnte/sollte
Ja, und ja, ich bleibe positiv und warte auf den Tag an dem das dann Alles in Harmonie läuft.

[Redeemer]

Ach ja, noch schöner ist das alles bei TDateTime, aka Double. Da die ja auch semantisch nicht dasselbe sind.

Delphi-Quellcode:

procedure Tuwat(const Wuppdi: TDateTime); overload;
procedure Tuwat(const Wuppdi: Double); overload;

Ruft nicht immer das auf, was man denkt. Mit var scheint es besser zu laufen.
Und die Codevervollständigung/Programmierhilfe zeigt zu manchen Datums-Funktionen weder TDateTime noch Double an, sondern Extended...