Generische Interface-GUIDs

[jaenicke]

Zitat von freimatz:

Bei generische interfaces über Modulgrenzen hinweg - selber Schuld wer sowas dort verwenden will.

So ungewöhnlich finde ich z.B. TList<T> nun nicht...

Ich fände es schon praktisch, wenn ich das nicht über Tricks in der Schnittstelle zu C# realisieren müsste. Es funktioniert zwar, ist aber zusätzlicher Aufwand, wenn auch nicht sonderlich viel. Da ich unter C# nicht direkt in den generischen Typ casten kann, habe ich ein nicht generisches Interface plus Klasse von den generischen Typen abgeleitet. Dorthin kann ich casten, obwohl der Quellcode komplett in der Elternklasse liegt...

[freimatz]

Entweder reden wir total aneinander vorbei oder ...
Wenn Du ein Modul in Delphi hast und dort eben TList<TBla> und ein anderes Modul in C# - wie übergibst Du dann sowas? Ich kenne Übergaben nur mit OLE wobei die Typen für die Schnittstelle in einer IDL definiert werden. Ich wüsste nicht ob und wie da Generics überhaupt gehen.

[himitsu]

Rein technisch sind die Generics oder nicht vollkommen egal-

Du könntest auf einer Seite auch eine generisches Interface haben und auf der anderen Seite ein Normales ... sie müssen nur die gleiche GUID haben und eine Tabelle von Methoden, die nichtmal gleich heißen müssen, weil es ist nur der Index wichtig, also die Reihenfolge/Anzahl und die Parameter-Definition und das was diese Methoden machen sollen.


Das Interface ist nur ein Zeiger.
Zum Prüfen und Konvertieren mit einer GUID ... will man nichts prüfen und auch nicht in ein anderes Interface casten, dann ist die GUID egal.

[jaenicke]

Zitat von freimatz:

Entweder reden wir total aneinander vorbei oder ...
Wenn Du ein Modul in Delphi hast und dort eben TList<TBla> und ein anderes Modul in C# - wie übergibst Du dann sowas? Ich kenne Übergaben nur mit OLE wobei die Typen für die Schnittstelle in einer IDL definiert werden. Ich wüsste nicht ob und wie da Generics überhaupt gehen.

Ich habe eine allgemeine Schnittstelle geschrieben, mit der man Interfaces (inkl. generische Interfaces) direkt zwischen verschiedenen Modulen, konkret zwischen Delphi-Anwendungen, Delphi-DLLs und C#-Assemblys, austauschen kann. Man kann also einfach eine C#-Assembly laden, wobei durch die integrierten Klassen automatisch eine Verbindung etabliert wird. Danach kann man dann einfach über generische Methoden Interfaces anfragen, die in anderen Modulen registriert wurden.

Auf diese Weise kann ich mir einfach z.B. aus einer geladenen C#-DLL ein Interface IExample holen und die Methode Run aufrufen.
Delphi:

Delphi-Quellcode:

if TBlub.TryGet<IExample>(Example) then
  Example.Run(42);

C#:

Code:

if (Blub.TryGet<IExample>(ref Example))
{
  Example.Run(42);
}

Anders als mit anderen Lösungen brauche ich dafür keine Registrierung der Assembly oder ähnliche Voraussetzungen. Es funktioniert komplett portabel, sofern die verwendete .NET Version installiert ist. Man muss bei den Interfaces ein paar Regeln, z.B. für Strings (die Marshalling-Attribute brauchen), beachten, aber ansonsten ist das recht intuitiv nutzbar.

Auf Delphi-Seite klappt das auch mit generischen IList<T> Interfaces problemlos. Auf C#-Seite muss ich dafür wie schon geschrieben eine nicht-generische Klasse ableiten, aber auch da ist es mit wenigen Zeilen erledigt, die ich zudem nur kopieren und mit dem konkreten Typ versehen muss.

Aber ich glaube das führt hier zu weit...

Zitat von himitsu:

Das Interface ist nur ein Zeiger.
Zum Prüfen und Konvertieren mit einer GUID ... will man nichts prüfen und auch nicht in ein anderes Interface casten, dann ist die GUID egal.

Ja, es wäre schön, wenn das auch bei C# ginge...

[jaenicke]

Der Beitrag ist nun schon älter, aber falls darüber mal jemand stolpert, möchte ich ergänzen, dass ich die angesprochene Funktionalität nun in neu geschriebener Form veröffentlicht habe:
https://www.delphipraxis.net/213199-...ng-dlls-c.html

[MyRealName]

Zitat von Uwe Raabe:

Wenn wir hier schon bei Wünsch dir was sind, dann wäre dies hier etwas weniger invasiv:

Delphi-Quellcode:

type
  IGenItf<T> = interface
    ['<AutoGUID>']
    function Foo: T;
    procedure Poo;
end;

Hätte man da nicht Probleme, wenn ich dieses Interface in EXE und DLL rein-kompiliere, es dann aber eine jeweils andere GUID bekommen könnte und dadurch nicht mehr das "gleiche" interface wäre ?

[Uwe Raabe]

Zitat von MyRealName:

Hätte man da nicht Probleme, wenn ich dieses Interface in EXE und DLL rein-kompiliere, es dann aber eine jeweils andere GUID bekommen könnte und dadurch nicht mehr das "gleiche" interface wäre ?

Man müsste dann halt sicherstellen, dass ein IGenItf<string> bzw. IGenItf<Integer> natürlich immer dieselbe GUID bekommt - wobei ich das als nur schwer stabil umzusetzen einschätze. Sollte die Auto-GUID bei jedem Kompilat anders sein, schließt das natürlich den beschriebenen Anwendungsfall aus.

[himitsu]

AutoGUIDs kann man natürlich immer nur innerhalb des selben Compilates benutzen.
* Zur Laufzeit bleibt diese GUID dann natürlich unverändert.
* Zwischen zwei Compilierungen könnte sie sich ändern, außer man nutzt z.B. sowas wie eine Cache (Delphi könnte sich diese GUIDs z.B. für Pfad zur Unit, zusammen mit dem implementierten TypeName merken)
* aber egal ... debuggen tut man eh nur ein Compilat und hat doch normal keine Verbindung zu anderen Debugsessions

[jaenicke]

Möglich wäre das schon, ich hatte dazu ja schon etwas geschrieben. Der Compiler müsste eine Textdatei erstellen, die diese Zuordnung enthält und auch vorher nachschauen, ob eine Definition bereits enthalten ist. Da würde ja die Zuordnung über den kompletten Namen des generischen Interfacetyps reichen. Dann würde man diese generieren und erweitern lassen und genauso wie alles andere einchecken.

Das wäre meiner Meinung nach auch der einzige wirklich gangbare Weg, denn:
- Nur so bleiben die GUIDs für einen konkreten Typ stabil
- Nur so kann der Compiler diese über mehrere Kompilate usw. hinweg stabil halten
- Und nur so kann man diese GUIDs dann als Liste für andere Sprachen wie C++ veröffentlichen

Der Implementierungsaufwand wäre vermutlich auf diesem Weg nicht einmal besonders hoch.

Ich habe in der Zwischenzeit eine RTTI-basierte Lösung ins Auge gefasst. Vielleicht komme ich im Zuge des AppCentral-Projekts doch noch dazu, mir das einmal anzuschauen.