Plugin-System mit Interfaces und DLLs

[jbg]

Zitat von xaromz:

Aber wie wäre es eigentlich damit, und hier sind wir wieder beim Thema des Threads, wenn das Objekt zwei Interfaces implementiert, wobei nur das eine an das Plugin weitergegeben wird, während das andere im Hauptprogramm verwendet wird? So bräuchts man sich nicht mit diesem Problem rumschlagen.

Hatte ich das nicht schon vorgeschlagen?

Zitat von jbg:

Aber wenn man es richtig macht, dann sollte man besser ein weiteres Interface deklarieren, dass dann den Zugriff auf die "versteckten" Eigenschaften erlaubt

[xaromz]

Hallo,

Zitat von jbg:

Zitat von xaromz:

Aber wie wäre es eigentlich damit, und hier sind wir wieder beim Thema des Threads, wenn das Objekt zwei Interfaces implementiert, wobei nur das eine an das Plugin weitergegeben wird, während das andere im Hauptprogramm verwendet wird? So bräuchts man sich nicht mit diesem Problem rumschlagen.

Hatte ich das nicht schon vorgeschlagen?

Zitat von jbg:

Aber wenn man es richtig macht, dann sollte man besser ein weiteres Interface deklarieren, dass dann den Zugriff auf die "versteckten" Eigenschaften erlaubt

Tatsache. Hatte ich überlesen.

Gruß
xaromz

[negaH]

Darum geht's mir, ich will nur auf diese Stolperfalle hinweisen. Und hier könnte der Delphi-Compiler tatsächlich erkennen, dass ich das Objekt nicht freigeben will und noch einen Referenzblock rumbasteln. Da Delphi das nicht macht, kann man es selbst machen. Nein, und das darf der Compiler eben nicht, bzw. er kann es auch garnicht.
Das verhalten ein Object zu erstellen und dieses dann impliziert als Interface nach Gebrauch zerstören zu lassen ist absolut erwünscht und korrekt. Nicht nur aus Sicht eines Delphi Programmierers sondern aus genereller Sicht bei der Benutzung von Interfaces. Sobald man auf die Ebene von Interfaces wechselt gelten deren Regeln auch für Objekte, Punkt.

Was übrigens das Gleiche macht, wie ich, nur implizit statt explizit. Das Gleiche im Sinne der internen Arbeitsweise ist nicht das Gleiche im Sinne des Verstehens, Lesbarkeit und Portierungssicherheit eines Sources. Ich kann die explizite Anwendung von ._AddRef und ._Release im Vergleich zur Benutzung einer Interfacevariablen und dem Asunuztzen der natüelichen Fähigkeiten des Compilers nicht empfehlen.

Aber wie wäre es eigentlich damit, und hier sind wir wieder beim Thema des Threads, wenn das Objekt zwei Interfaces implementiert, wobei nur das eine an das Plugin weitergegeben wird, während das andere im Hauptprogramm verwendet wird? So bräuchts man sich nicht mit diesem Problem rumschlagen. versteht und benutzt man Interfaces einfach auf korrekte Art dann ist das KEIN Problem ergo ist die doppelte Benutung von doppelten Interfaces nur ein doppeltgemoppelter Aufwand der unnötig ist.

Das ist so also ob man an einem Auto noch zusätzlich 4 grüne Räder anbringt damit man mit 4 scharzen Rädern die an 4 roten Räder montiert sind fahren kann.

Wie gesagt das einzigste Problem ist das man als Entwickler sich in die Funktionsweise von Interfaces einarbeiten muß. Das spezielle Verhalten von Objekten ohne RefCounter als Interfaces mit RefCounter ist nicht nur in Delphi so sondern auch in anderen Programmiersprachen. Das "Problem" ansich ist schon sehr oft, schon vor Jahren, in den einschlägigen Newsgroups diskutiert worden.
Es ist defakto garkein "problem" im Compiler oder im Konzept Object->Interface, sondern nur ein Problem im Verständnis des Programmiers.

Fange doch mal an das Pferd richtig aufzuzäumen und entwickle mal von Grund auf ein eigenes Konzept von Interfaces und RefCounter innerhalb von Klassen. Du wirst sehen, egal wie du es konstruierst du wirst IMMER auf exakt das Verhalten wie es jetzt in Delphi ist kommen.

Gruß Hagen

[xaromz]

Hallo,

Zitat von negaH:

Sobald man auf die Ebene von Interfaces wechselt gelten deren Regeln auch für Objekte, Punkt.

Die Regeln von Interfaces können niemals für Objekte gelten, da Objekte keine Interfaces sind. Aber ich weiß, was Du meinst .

Zitat von negaH:

versteht und benutzt man Interfaces einfach auf korrekte Art dann ist das KEIN Problem ergo ist die doppelte Benutung von doppelten Interfaces nur ein doppeltgemoppelter Aufwand der unnötig ist.

Das ist so also ob man an einem Auto noch zusätzlich 4 grüne Räder anbringt damit man mit 4 scharzen Rädern die an 4 roten Räder montiert sind fahren kann.

Schade, dass Du nicht verstanden hast, um was es eigentlich geht.

Zitat von negaH:

Fange doch mal an das Pferd richtig aufzuzäumen

Zitat von negaH:

und entwickle mal von Grund auf ein eigenes Konzept von Interfaces und RefCounter innerhalb von Klassen. Du wirst sehen, egal wie du es konstruierst du wirst IMMER auf exakt das Verhalten wie es jetzt in Delphi ist kommen.

Das weiß ich durchaus. Das System ist ja auch gut so. Wie gesagt, ich weise nur auf die möglichen Seiteneffekte hin.

Gruß
xaromz

[negaH]

@Xarmoz:

Ich verstehe deine "Probleme" sehr wohl, aber sehe es einfach nicht als "Problem". Du machst aus deinem Problem ein Problem das angeblich in Delphi existieren soll und schlägst Lösungen vor die dein "Problem" im Endeffekt nur noch verschlimmbesseren.

Und exakt damit habe ICH ein Problem. Und das habe ich versucht hier für andere Leser des Threads exakt herauszuarbeiten.

Es existiert einfach kein Problem mit Objekten und Interfaces in Delphi, das was problematisch ist ist einfach die Tatsache des Verständnisses wie alles zusammenhängt.

Schlußendlich meine ich aber das wir beide auf das Gleiche hinauswollen (und das ist das Einzigste ws zählt), es aber eben aus anderen Blickwinkeln betrachten

Gruß Hagen

[xaromz]

Hallo,

Zitat von negaH:

Schlußendlich meine ich aber das wir beide auf das Gleiche hinauswollen (und das ist das Einzigste ws zählt), es aber eben aus anderen Blickwinkeln betrachten

Gruß
xaromz

[MasterEvil]

Huhu,

erstmal sorry, dass ich so lang nichts geschrieben hab, war erst im Urlaub und danach hab ich eure Anmerkungen erstmal umgesetzt.

Ich in jetzt so gut wie fertig (jedenfalls mit Version 1, das ding wächst ja mit meinem PM mit) und es klappt wunderbar.
Vielen dank also für eure ausführliche Hilfe!

Da ihr euch ja so gut auskennt, habt ihr eventuell ja auch eine Lösung für dieses (dazugehörige) Problem:
DLL Formular Problem

greetz
Steffen