Eigene Ableitung von TThreadList<T> - Habe ich einen Denkfehler?

[Sir Rufo]

Zitat von Dejan Vu:

Ich dachte immer, List[Index] :=Foo macht etwas anderes, als List.Insert(Index,Foo Wenn dem so wäre, wäre der Tipp vielleicht suboptimal.

In Kombination mit vorherigem Remove

[Dejan Vu]

Zitat von Sir Rufo:

In Kombination mit vorherigem Remove

"Dann ist aber der Eintrag nicht mehr an der selben Stelle." sagte Dejan und wunderte sich kurz darauf, wieso die Meute ihn an Füßen und Schultern packte, horizontal hin und her schaukelte, um ihn in hohem Bogen und unter hämischem Johlen, Grölen und Beifallklatschen der Anwesenden die Böschung hinunter zu werfen.

Sir Rufo, der Edle (wie er von seinen Vasalen genannt wird), schüttelte nur augenbrauenwackelnd den Kopf und ritt ins Wochenende.

Dejan, wieder zu sich gekommen, krabbelte die Böschung hinauf, setzte sich wieder hin und schrieb:

Zitat von TiGü:

Warum ist das so und wie geht es besser?

Du bietest dem Anwender die Möglichkeit, Daten einzeln in die Threadliste zu schreiben (wie man das von einer normalen Liste gewohnt ist). Es besteht also die Gefahr, das er (der Anwender, also ein anderer Programmierer) diese sehr praktische Möglichkeit nutzt, anstatt die anstehenden Änderungen zu sammeln, um sie explizit durch einmaliges Lock/Unlock in die Liste einzutragen.

Die Implementierung der 'Put' Methode ('Set' hat sich eigentlich als Name etabliert, genauergesagt :SetItem', wenn 'Item' der Name der Property ist) an sich ist vollkommen ok.

[TiGü]

Zitat von Dejan Vu:

Zitat von TiGü:

Warum ist das so und wie geht es besser?

Du bietest dem Anwender die Möglichkeit, Daten einzeln in die Threadliste zu schreiben (wie man das von einer normalen Liste gewohnt ist). Es besteht also die Gefahr, das er (der Anwender, also ein anderer Programmierer) diese sehr praktische Möglichkeit nutzt, anstatt die anstehenden Änderungen zu sammeln, um sie explizit durch einmaliges Lock/Unlock in die Liste einzutragen.

Du meinst ein klassisches AddRange()?
Ja, das wäre noch denkbar.

[Dejan Vu]

Ja genau. Dann gibt es zwar immer noch Dumpfbacken, die das nicht verwenden, aber besser wäre das. Ich persönlich würde den Setter weglassen, aber nicht in deinem Fall: Wir reden aber hier ja nicht von einer allgemeinen Threadlist, sondern einem mit möglichst wenig Aufwand zu implementierenden threadsicheren Ersatz für deine Listen und da geht Kompatibilität vor Performance. Erstmal soll es laufen. Den Setter kannst Du dann später irgendwann wegschmeißen und schauen, wie viel Arbeit das Umschreiben wäre...

Ich wollte ja nur darauf hinweisen

[himitsu]

Natürlich könnte man auch direkt LockList und UnlockList aufrufen
und dann kann man ja dennoch problemlos mehrfach etwas in der Liste machen.


CriticalSections sind schneller, als man vielleicht denkt.

[TiGü]

@Devan:
Warum die Setter-Methode wegschmeißen?
Es gibt immer Situationen, wo man wirklich nur ein Element hinzufügen will.

@Himi:
Aber auch nur bei einer eigenen Implementierung von TThreadList<T>.
Schau mal was in deinen XE3 in Zeile 2495 in System.Generics.Collections steht.

[Dejan Vu]

Zitat von TiGü:

@Devan:
Warum die Setter-Methode wegschmeißen?
Es gibt immer Situationen, wo man wirklich nur ein Element hinzufügen will.

Natürlich, aber dein Kollege könnte dazu verleitet werden, Elemente nur auf diese Art zu verändern, obwohl das eben unperformant ist.

Es ist nur ein Hinweis, das man Klassen auch gegen Idioten schützen kann, und manchmal muss.