Wieso suck't eigentlich TList?

[alzaimar]

Ja ja, blöder Header. Aber was ich mal wissen will:
1.Was ist denn an TList so schlimm?
2.Und was ist denn besser?

Danke für die Aufklärung.

[Aenogym]

Zitat:

Zitat von alzaimar

1.Was ist denn an TList so schlimm?

ähm, das frag ich mich auch. wie kommst du darauf?

aenogym

edit: blöde tippfehler...

[Robert_G]

Moin Alzi :hi:
Das hast du sicher von mir gelesen.
Generell hben allen fast streng tpisierten Nachfahren vn TList das Problem, dass ich sie auf TList casten und einen Pointer auf einen Gartenstuhl reinwerfen kann. Add, Insert sind nunmal nicht vrtuelle und deshalb kann man dort im Nachfahren keine Typenprüfung vornehmen.
Das stört mich dabei am meisten. Außerdem steht sie in Classes.pas und ich persönlich versuchte innerhalb der zentralen Units die Finger davon zu lassen.[1]
Es gibt noch ein paar mehr Dinge, die ich persönlich nicht daran mah, aber die will ich jetzt auch nicht alle auflisten...

[1]So kann man sehr kleine Packages schnell austauschen, ohne die Anwendung dazu zu zwingen die VCL extern zu referenzieren
Außerdem ist dermaßen mit Funktionen, typen, Klassen, Konstanten zugestopft, dass die sich auch in der Code Completion breit machen...

[Daniel]

Zitat:

Zitat von alzaimar

Ja ja, blöder Header.
[...]

...nun - wenn Du es selber schon so empfindest, warum drängst Du uns allen dann diesen Titel auf? Ändere ihn bitte umgehend.


Eine TList per se ist nichgts Schlechtes, sie hat u.A. die von Robert aufgelisteten Eigenschaften - darüber sollte man sich bei deren Benutzung jedoch im Klaren sein.

[negaH]

Jo, und was soll an Unit Classes so schlecht sein ? Irgendwo muß es in jeder Library einen Anfang geben.

Und wenn man mit TList nun einfach nur Pointer verwalten will ?

Zitat:

Generell hben allen fast streng tpisierten Nachfahren vn TList das Problem, dass ich sie auf TList casten und einen Pointer auf einen Gartenstuhl reinwerfen kann.

Ja und ? die Frage ist doch WIE du castest, wahrscheinlich ein harter Typcast der die Compiler Typprüfung deaktiviert. Wenn man aber TList so benutzt wie es die Borländer vormachen dann sind sehr häufig Objekte darin gespeichert, und die sollte man mit "as" oder "is" casten.
Saubere Typcasts an sich sind doch kein Übel sondern in jeder OOP Sprache vorhanden und auch notwendig.

Falls man mehr Aufwand treiben will dann kann man natürlich für jede mögliche Art von Datentyp/Klassentyp immer wieder eine eigenes TList Object erzeugen. Jo, das wäre wohl dann OOP konform, alles mit 1000'enden Klassen zupflastern bis man den Wald vor lauter Objekten nicht mehr sieht.

Ich meine TList hat eine Existenzberechtigung und gerade weil sie eben nicht jeden Anwednungsfall abdenken kann und auch garnicht den Anspruch darauf erheben will.

Gruß Hagen

[jbg]

Also wenn ich Objekte in einer Liste verwalten will, nehme ich immer TObjectList. Der kann ich schon mal ohne expliziten Typecast zu TList keine wildfremden Zeiger übergeben. Und dann muss man eben TObjectList als Basisklasse ansehen und somit bei den Parametern angeben.

Beim Ableiten von TObjectList muss man für speziellere Klassen "nur" die Add, Insert und Items[] Methoden/Properties neu implementieren und dort den Typecast machen. (Dafür hätte ich sehr gerne Templates).
Man muss dabei aber konsequent sein und dann auch immer TXyzList statt TObjectList als Parametertyp angeben, wo man auch eine TXyzList erwartet. Ich gebe z.B. recht selten TObjectList als Typ an, wenn es sich nicht gerade um eine Funktion handelt, die nicht direkt auf den Daten arbeitet, wie z.B. nil-Items entfernen. Aber solche Funktionen sind recht rar.

[Robert_G]

Ich glaube ihr habt das schlimmer eausgelesen als es gemeint war.
Ich bezog mich eigentlich darauf:

Zitat:

1.Was ist denn an TList so schlimm?

Da eine Containerklasse keine "Rocketcience" ist, sehe ich kaum einen Grund nicht meine eigene zu schreiben, wenn ich etwas an den gegeben auszusetzen habe. ;)

Zitat:

Zitat von Robert_G

Generell hben allen fast streng tpisierten Nachfahren vn TList das Problem, dass ich sie auf TList casten und einen Pointer auf einen Gartenstuhl reinwerfen

Ich minimiere halt gerne die möglichen Fehlerquellen so gut es geht, wenn ein Kollege eine API von mir nutzt, ist es nicht unmöglich, dass das passieren könnte. Also warum muss ich es unbedingt ermöglichen? :gruebel:

[Sidorion]

Wenn Dich das mit dem Typcast stört, dann überschreib einfach Notify. Hier kannst Du dann bequem den Typ des geaddeten Elements prüfen und gegebenenfalls Gegenmaßnahmen einleiten.

[edit=sakura] SINNLOSEN-Teil gelöscht. Bitte erspare Die das in Zukunft :!: Mfg, sakura[/edit]

[generic]

warum nutzt du tlist direkt?

nutz doch lieber eine vererbte variante davon mit typisierten parametern.
klar intern wäre die immer noch mit pointer usw. aber es kommt ja auch auf das interface an.

[CLRS530]

Am besten ist eh immer sich eine Liste selbst zu schreiben :)

Zumindestens mache ich das immer.