Wer meint es besser zu wissen bzw. sein Anwendungsfall es unbedingt erfordert, muss ja nicht von TInterfacedObject ableiten,
Die RefCount Methoden kann man zwar überschreiben, aber die Grundproblematik von Delphi wird man dadurch nicht los.
Delphi ruft z.B weiterhin lustig die Refenz-Count Methoden von Objekten auf, auch wenn das Objekt z.B. schon freigegeben wurde.
Die zur Zeit einzig sinnvolle Lösung für das Problem nennt sich Free-Pascal...
Die "automatische" Referenzverwaltung von Inferface-Objekten ist in meinen Augen sehr bequem und ermöglicht ein sehr komfortables modernes programmieren.
Ich denke, dass jemand, der "automatische" Referenzverwaltung für bequem hält, vom Thema insgesamt herzlich wenig verstanden hat.
Das ist fast genauso beknackt wie die Forderung der
ActiveX Retro-Gurus, dass man Objekte und Interfaces nicht mischen sollte.
Leute. Nehmt einfach einen vernünftigen Compiler und reitet nicht für immer rum auf diesen Lehrsätzen für
COM-Interfaces, die Microsoft mal in der Antike verkündet hat.
Hast du nur ein Objekt von Typ IInteger vorliegen, musst aber schauen ob ISomeThing unterstützt wird (oder umgekehrt) -> wie sollte man es sonst machen?
Ein Fehler (z.B. bei dem Problem mit der Liste) liegt schon an der Stelle, wo man so ein Objekt erzeugt und es dann in einen anonymen Container wirft. Eine bessere Lösung wäre die Objekte in typsicheren Listen zu speichern, und nicht erst zur Laufzeit die Objekte herauszufiltern. Wer Typsicherheit von der Compilezeit in die Laufzeit schiebt, darf sich nicht beschweren, dass es Probleme gibt.