Property als Array

[Robert_G]

Das Ding hieß TTokens, deshalb dachte ich du packst dort deine Tokens rein.
Interessant wäre ab dem Punkt, wenn du unterschiedliche Tokenarten von TToken ableitest (Operatoren, Typen, Keywords,...).
Und so kompliziert ist das gar nicht. Es gibt doch Ctrl+Shift+C , effektiv habe ich an jeder Lister bestimmt weniger als 30 Zeilen getippt. Von denen ein Großteil der Buchstaben durch Code completion reingefumpt wurde.

Die Verwendung ist halt mega einfach und darum gates doch eigentlich, oder?

Zitat:

Wozu also eine TObjectList UND eine Klasse, in der die meisten (oder alle?) der ObjectList-Methoden drin vorkommen, die im Endeffekt nur die gleiche Methode einer echten TObjectList aufrufen. Ich halte sowas nicht nur für unnötig, sondern auch noch für Zeitverschwendung.

Der Sinn ist type safety. Du bekommst nicht nur einen compilerfehler, wenn man etwas falsches reinwirft, du musst auch keine Type casts mehr machen.
Man darf das Wort Zeitverschwendung nicht so überstrapazieren. Es kostet wenige Minuten diese strong typed ObjectList zu tippen (wesentlich weniger Zeit als du für den letzten Absatz gebraucht hast ), aber bei jeder Verwendung sparst du dir Typecasts und ein paar Prüfungen.

Verstehe mich nicht falsch, ich will dich hier in keine Ecke drängen.
Ich hatte eigentlich nur das TTokens falsch interpretiert und nun musste ich einfach zur "Zeitverschwendung" Stellung nehmen...

[malo]

Hi Robert!

Zitat von Robert_G:

Das Ding hieß TTokens, deshalb dachte ich du packst dort deine Tokens rein.

Stimmt auch. Die Klasse ist auch etwas größer, ich hab aber nur die Methoden/Properties drin gelassen, die für das Problem relevant sind.

Zitat von Robert_G:

Interessant wäre ab dem Punkt, wenn du unterschiedliche Tokenarten von TToken ableitest (Operatoren, Typen, Keywords,...).

Auch das mach ich schon. Ich unterscheide im Moment schon zwischen Zahlen, Bezeichner (Typen, Keywords etc.), Strings und Variablen (die mit einem $ eingeleitet werden und daher seperat ausgewertet werden können). Das ganze ist jedoch nur der erste Schritt. Im zweiten Schritt des Parsens unterscheide ich zwischen bestimmten Bezeichnern (prüfe, ob es ein Keyword ist oder vielleicht doch ein Operator wie beispielsweise not, oder vielleicht doch eine Funktion/Prozedur.

Zitat von Robert_G:

Und so kompliziert ist das gar nicht. Es gibt doch Ctrl+Shift+C , effektiv habe ich an jeder Lister bestimmt weniger als 30 Zeilen getippt. Von denen ein Großteil der Buchstaben durch Code completion reingefumpt wurde.

Tja, Ctrl+Shift+C funktioniert schonmal bei meinen PE-Versionen nicht (ich hab zwar D5 Pro, aber die Version benutz ich nicht so gerne, da die nicht so ganz legal ist (eine SSL-Version von meinem Bruder. Ich hab keine eigene Lizenz dafür)).

Zitat von Robert_G:

Zitat:

Wozu also eine TObjectList UND eine Klasse, in der die meisten (oder alle?) der ObjectList-Methoden drin vorkommen, die im Endeffekt nur die gleiche Methode einer echten TObjectList aufrufen. Ich halte sowas nicht nur für unnötig, sondern auch noch für Zeitverschwendung.

Der Sinn ist type safety. Du bekommst nicht nur einen compilerfehler, wenn man etwas falsches reinwirft, du musst auch keine Type casts mehr machen.
Man darf das Wort Zeitverschwendung nicht so überstrapazieren. Es kostet wenige Minuten diese strong typed ObjectList zu tippen (wesentlich weniger Zeit als du für den letzten Absatz gebraucht hast ), aber bei jeder Verwendung sparst du dir Typecasts und ein paar Prüfungen.

Wie gesagt: Ich komme notfalls auch mit einem einfach Array aus. Ganz davon zu schweigen, dass ich von Type Casts KEINE Ahnung habe...

Ich will ja nur Strings in der Liste speichern. Es würde also ein Array of String auch tun. Wofür also eine extra Klasse erstellen, wenn es auch leichter geht? Klar, um die ewigen SetLength's zu vermeiden könnte man noch eine Add-Methode implementieren, aber mehr ist ehrlich nicht nötig.

Zitat von Robert_G:

Verstehe mich nicht falsch, ich will dich hier in keine Ecke drängen.
Ich hatte eigentlich nur das TTokens falsch interpretiert und nun musste ich einfach zur "Zeitverschwendung" Stellung nehmen...

Ich fühle mich auch nicht in die Ecke gedrängt. Ich halte es einfach nur für unnötig, einen solchen Aufwand zu betreiben, wenn es halt viel einfacher geht. Ich sehe da keinen Sinn drin.

Und ich gebe zu, die "Zeitverschwendung" scheint weniger Aufwand zu sein, als ich zuerst dachte.

Ich bin dir natürlich sehr dankbar, wenn du dir nähere Gedanken zu meinem "Problem" machst und auch für Vorschläge offen. Aber manche Sachen halte ich einfach für unnötig und übertrieben.

[SirThornberry]

zur Ausgangsfrage - Wenn "fOperators" bereits ein Array of String ist wozu machst du dann noch die eckigen klammern bei deinem property?
property Operators[Ndx: integer]: String read fOperators write fOperators; Denn wenn fOperators bereits das Array ist hättest du ja sonst ein 2 dimensionales.

am einfachsten ohne Get und SetMethode wäre es da doch

Delphi-Quellcode:

Type
  TDynStringArr = Array of String;
[...]
private
fOperators: TDynStringArr;
[...]
property Operators: TDynStringArr read fOperators write fOperators;

[malo]

Zitat von SirThornberry:

zur Ausgangsfrage - Wenn "fOperators" bereits ein Array of String ist wozu machst du dann noch die eckigen klammern bei deinem property?
property Operators[Ndx: integer]: String read fOperators write fOperators; Denn wenn fOperators bereits das Array ist hättest du ja sonst ein 2 dimensionales.

am einfachsten ohne Get und SetMethode wäre es da doch

Delphi-Quellcode:

Type
  TDynStringArr = Array of String;
[...]
private
fOperators: TDynStringArr;
[...]
property Operators: TDynStringArr read fOperators write fOperators;

Danke, so scheints auch zu gehen

[Nogge]

Dazu eine Frage: Wieso kann ich nicht einfach

Delphi-Quellcode:

public
Operators: Array of String;

anstelle einer zusätzlichen (unnötigen?) property schreiben?

[malo]

Zitat von Nogge:

Dazu eine Frage: Wieso kann ich nicht einfach

Delphi-Quellcode:

public
Operators: Array of String;

anstelle einer zusätzlichen (unnötigen?) property schreiben?

Nunja, eine Property würde beispielsweise auch die Speicherzuweisung übernehmen können und sowas... ist halt kein Muss, aber es ist halt "OOP-Konform". Alles eine Frage des Programmierstils, denke ich. Ich wollte es damals so haben, und habs dann auch so gemacht

[DevilsCamp]

Des Weiteren hast du bei einer Property die Möglichkeit zu überprüfen, ob der zugewiesene Wert auch in dein "Konzept" passt.

Soll heißen:
Wenn deine Strings so aufgebaut werden müssen, dass der String IMMER mit "XYZ" beginnt, dann kannst du mit einer Array-Property da schon eingreifen und dir evtl. viel Schreibarbeit und Zeit bei der Fehlersuche sparen.