Interface "überladen" vorhandener Methoden?

[Stevie]

Meine Aussage bezog sich auf die ausgeschaltete Referenzzählung für Interfaces in einer Klasse (z.B. TComponent). Bei einer solchen bringt auch ARC nix, da die Interface Referenz (welcher aber ja wie gesagt, nix zum RefCount beiträgt) langlebiger sein kann, als die Objektinstanz (welche ja durch ARC bei Verlassen des Scopes für das Freigeben sorgt)

[himitsu]

Stimmt, da hast du recht.

Wenn bei aktivem ARC die Interfacereferenzen ans ARC weitergeleitet werden,
dann müsste man ja bei allen Interfaces, welche "anders" zählen, ja das ARC deaktiviert werden.
So gesehn, wurde das dann doch falschrum implementiert, weil das ARC hätte besser seine Referenzen ans Interface weitergeben müssen?



Toll, noch mehr zum Grübeln.
Mein Model für einen kreuz- und querverlinkten Interfacebaum, aus mehreren Interfaces, die sich gegenseitig referenzieren sollen, wird immer verwirrender.
Ich wollte eigentlich eine Vorlage schaffe, wo soein Verhalten "sicher" ablaufen kann.
- jeder kennt/referenziert sich gegenseitig (Parent und Childs)
- Childs werden freigegeben, wenn sie weder extern, noch von einem/mehreren Parents referenziert werden
- Parents bleiben aber so lange vorhanden, wie extern auf sie referenziert wird, oder von/auf deren Parents, bzw. auf deren Childs
- wird der oberste Parent freigegeben, und es existieren weder auf ihn, auf dessen Childs und deren Childs eine Referenz, erst dann verschwindet alles
- ...

Zum Glück hab ich die neuen Schnittstellen für's himXML so geschaffen, daß es dort "extern" und intern auch nur kurz beim Erstellen niemals Objektreferenzen gibt,
sonst hätte mir das blöde ARC jetzt schon einen strich durch die Rechnung gemacht. Ich hoffe zumindestens, daß es das nicht macht (prüfen kann ich's ja nicht mehr)

[Stevie]

Zitat von himitsu:

Wenn bei aktivem ARC die Interfacereferenzen ans ARC weitergeleitet werden,
dann müsste man ja bei allen Interfaces, welche "anders" zählen, ja das ARC deaktiviert werden.
So gesehn, wurde das dann doch falschrum implementiert, weil das ARC hätte besser seine Referenzen ans Interface weitergeben müssen?

Wie soll ARC an Interfaces irgendwas weitergeben. Die Referenzzählung bei Interfaces ist ein Implementierungsdetail der implementierenden Klasse.
Wenn man es genau betrachtet und berücksichtigt, dass man seinen Code nicht von Implementierungsdetails abhängig machen soll, bewegt man sich bei der Referenzzählung und Programmierung gegen Interfaces genau genommen schon ziemlich in einer Grauzone.

Gegen ein grausames Design, in dem man Objekt und Interface Referenzen bunt vermischt und keinen Plan mehr über die genauen Lebenszyklen und Scopes der Dinger hat, ist noch kein Kraut gewachsen. Man könnte jetzt wieder für einen GC argumentieren, aber auch den kann man verwirren, so dass ohne ihm auf seltsamste Weisen unter die Arme zu greifen, Speicherlecks entstehen.

[Der schöne Günther]

Oder anders herum. Es ist noch nicht allzu lange her, da hat der Java-GC immer gerne die Singletons gefressen