Moin,

warum kann man bei diesen komischen Listen nicht vorher prüfen, ob etwas da rein/raus darf?

Hä? Programmier es doch einfach. Nennt sich Wrapper. Aber Du kannst so einem Ding auch einen anderen Namen geben.

Sehe ich auch so. So eine Liste ist wie ein Eimer. Der soll robust sein und zuverlässig funktionieren.

Wenn ich statt dem Eimer eine selektive Reuse brauche dann baue ich mir das aus dem Eimer (Composition)

In den ersten TList<T> ginge das mit dem Selbermachen noch (halbwegs), aber ich hab jetzt den Code von XE8 gesehn und muß sagen "vergesst" es, denn jede Prozedur einzelne Prozedur zum Hinzufügen, Löschen oder Entfernen separat auf eine eigene TListHelper-Prozedur geht und die wiederzum alle weder in TList noch im Helper überschreibbar (virtual) sind.

Auch werden alle Events und virtuellen Methoden erst nach den Operationen aufgerufen, wo es dann schon zu spät ist.

Es gibt einfach keine Orte, wo man sich vorher rein hängen kann, um z.B. eine "nee, das darfst du nicht"-Exception auszulösen.
Ich kann also nur hinterher ein "das hättest du jetzt tun sollen" werfen.



Gut, man könnte jetzt in der TList nocheine TList/Array ablegen, welches nach den Operationen eine Kopie macht, über die ich es dann wieder rückgangig machen kann, aber das ist absolut keine Lösung.

"Komposition statt Vererbung" war eins der ersten Dinge die mir eingetrichtert wurden

Ich glaube Vererbung passt hier echt nicht.

Einfach ausgedrückt: Du schreibst Dir deinen Container, indem Du *nicht* von TList ableitest, sondern (heute) intern eine TList verwendest. Das macht deinen Container flexibler, weil so eine TList ist ja nun auch nicht das Gelbe vom Ei. Morgen gibt es vielleicht eine "TSuperDuperList" und dann änderst Du die Implementierung deines Containers und keine Sau merkt, das Du die TSuperDuperList mit der neuen TRaumZeitFalte verwendest, wodurch die Elemente schon gefunden werden, *bevor* überhaupt danach gesucht wurde.

Wäre halt zu einfach, wenn jemand an die Before-Events gedacht hätte.

Jetzt ist das so, daß man praktisch jede Methode (und die TList<> hat seeeeehhhhrrr Viele davon) überschrieben überdeckt werden müsste.
Und es kommen ständig neue Methoden dazu, die dann deine Überladungen umgehen.

Fazit: Man kann das vergessen und müsste eigentlich selber eine eigene TList schreiben, wo Emba nicht drin rumpfuschen kann. [edit] oder der Container

Ich muss Himitsu zustimmen. Eine OnBefore-Funktion ist m.E. mit Funktionen wie Sort gleichzusetzen und hat durchaus eine Berechtigung zur TList zu gehören. Grade bei der Generics-Version

Ansonsten bin ich wie Günther ein Fan von Komposition.

TList ist keine Komponente, sondern eine Klasse. Und so eine Klasse hat genau eine einzige Aufgabe: Implementierung einer Liste.

Gute Software zeichnet sich übrigens nicht dadurch aus, das man -wuppdiwupp- auf schnellstmöglichste Weise irgend ein Ding umsetzt, sondern eher dadurch, das das, was man umsetzt, nachhaltig ist, d.h. leicht zu verstehen, zu warten und zu erweitern ist.

Deine SW wäre mit TListen übersäht, wobei das OnBefore... ständig umgebogen würde. Hmmm....

Wozu soll man erst einen Wrapper bauen, wo doch das OnBefore die einzige wichtige Funktion ist, die man wirklich in der Liste gebrauchen kann?
Soll ich jetzt dutzende Methoden verpacken und jeweils mit der Check-Methode davor zur Liste umleiten, anstatt nur eine Stelle in der Liste zu haben?

Gerade die generische TList<> hat rein garnichts mehr mit der alten TList zu zun.
Alleine das Interface der TList<> ist knapp 400 Zeilen lang, mit unmassen an Methoden, die man fast alle Wrappen müsste, wenn man dem Endnutzer meiner Komponente auch alle Möglichkeiten offen lassen will. (TList als Child-Liste in einer Komponente, also für einen schönen Baum an Komponenten)