Generische Interface-GUIDs

[Dennis07]

Moin Loide,
habe das jetzt schon in vielen Gruppen diskutiert und alle fanden den Vorschlag eigentlich wirklich gut und wichtig.
Was wir brauchen sind einzigartig generierte GUIDs für generische Interfaces!

Was mich wirklich jedes mal abnervt ist folgendes Szenario:
Es ist ein gewöhnlicher Tag. Draußen zwitschern die Vögel, die Sonne scheint. Man sitzt so am PC und denkt sich nichts böses. Gut gelaunt deklariere ich ein generisches Interface, und will es mit verschiedenen Typparametern in einer Funktion benutzen. Was nicht geht, zumindest nicht richtig, weil beide Interfaces die gleiche VMT und die gleiche GUID benutzen, und somit weder von einander unterscheidbar, noch die Methoden des zweiten, dritten, ... Interfaces aufrufbar.

Also, von der Wahrheit eingeholt und vor der Sinnlosigkeit des Lebens erneut resignierend, deklariere ich einzeln n Ableitungen des Interfaces mit Typenspezifikationen.

Dabei könnte es so einfach sein. Eine Syntax wie diese hier könnte uns das Leben enorm erleichtern, und die Wirtschaft durch Zeiteinsparung bei der Entwicklung weit voranbringen:

Delphi-Quellcode:

type
  IGenItf<T> = geninterface
    // Keine GUID hier, denn die wird automatisch erzeugt
    function Foo: T;
    procedure Poo;
end;

Das Keyword geninterface habe ich einfach mal an dispinterface angelehnt und frei erfunden, bietet sich aber an.

Dann könnte man einfach folgendes schreiben:

Delphi-Quellcode:

type
  TImplObject = class(TInterfacedObject, IGenItf<Integer>, IGenIntf<String>)
    // Implementierungen
    function Int_Foo: T;
    procedure Int_Poo;
    function Str_Foo: T;
    procedure Str_Poo;
    // Delegationen
    function IGenItf<Integer>.Foo = Int_Foo;
    procedure IGenItf<Integer>.Poo = Int_Poo;
    function IGenItf<String>.Foo = Str_Foo;
    procedure IGenItf<String>.Poo = Str_Poo;
end;

Das mag jetzt nicht nach viel Ersparnis an Code aussehen, bei einigen Beispielen ist das aber äußerst beträchtlich.
Was haltet ihr davon?

[TiGü]

Und bei jeden Full Build kommt eine andere GUID bei raus? :roll:

[himitsu]

Es könnte auch sein, dass garkeine GUID generiert wird und die einfach nur 0000-000-00000-0000.... ist

Mir war so, als wenn der Compiler bei Interfaces "ohne" GUID eh gewisse Dinge verbietet / nicht kompilert, wie z.B. die Verwendung von IS und AS.
Somit wäre dabei die GUID dann eh egal, wenn sie nie verwendet würde.




Gab es bezüglich Generics bei Interfaces nicht hier mal irgendwo eine größere Diskusion/Thread?

Wenn man die GUID angibt, dann würde doch jede Ableitung die Gleiche GUID bekommen, was so auch nicht super gut wäre.

[jaenicke]

Poste doch einfach den Link zum Featurerequest, damit auch jemand dafür voten kann. Ansonsten passiert da ohnehin nichts, egal wie viel es in Foren diskutiert wird.

Automatisch generierte GUIDs würden jedenfalls nur einen Teil der Probleme lösen. Ich hatte das Thema GUIDs bei generischen Interfaces auch schon, wenn auch mit anderem Hintergrund. Mir fällt aber schlicht keine wirklich sinnvolle Lösung dafür ein. Deshalb hatte ich dazu auch keinen Featurerequest geschrieben bzw. erst einmal danach gesucht.

Nebenbei gibt es ähnliche Themen im Hinblick auf Casts usw. ja auch bei anderen Sprachen wie C#, wo man für generische Typen kein Marshalling für interop usw. hat.

[Uwe Raabe]

Berücksichtig man den Fakt, dass in Delphi zwei an verschiedenen Stellen deklarierte TList<string> auch formell zwei unterschiedliche Typen sind, sehe ich da noch einen sehr langen Weg bis sowas realisiert werden könnte.

[Stevie]

Mach halt einfach kein supports auf nen generisches interface

Zitat:

Zitat von Uwe Raabe (Beitrag 1511686)

Berücksichtig man den Fakt, dass in Delphi zwei an verschiedenen Stellen deklarierte TList<string> auch formell zwei unterschiedliche Typen sind

Wenn du mit "verschiedene Stellen" unterschiedliche Binaries meinst, dann ja, ansonsten nein

[himitsu]

Jupp, Generics werden beim Compilieren über eine Art globalen Cache verwaltet.
Wurde einmal ein generic implementiert/verwendet, und kommt an anderer Stelle nochmal "neu" vor, dann wird die bereits bestehende Deklaration verwendet.

z.B. TArray<irgendwas> in einer Unit und TArray<irgendwas> in einer anderen Unit sind somit identisch.
Im Gegensatz dazu sind "array of irgendwas" an beiden Stellen "neue" deklarationen und somit jeweils "eigene" Typen.

In einer anderen EXE/DLL natürlich nicht mehr, weil neues/anderes Compilat.

[Uwe Raabe]

Zitat:

Zitat von Stevie (Beitrag 1511688)

Wenn du mit "verschiedene Stellen" unterschiedliche Binaries meinst, dann ja, ansonsten nein

Ja, da hatte ich einen Knoten im Hirn. Das kommt davon, wenn man zu viele Sachen auf einmal macht.

[Dennis07]

Zitat:

Zitat von Uwe Raabe (Beitrag 1511686)

Berücksichtig man den Fakt, dass in Delphi zwei an verschiedenen Stellen deklarierte TList<string> auch formell zwei unterschiedliche Typen sind

Jo, aber das ist ja eine Klasse. Klassen identifizieren sich ja über die Klassenreferenz, Interfaces hingegen über ihre GUID. Wenn du zweimal das gleiche Interface mit der selben GUID hast, dann ist es auch das selbe. Das ist ja gerade der Sinn eines Interfaces, sonst bräuchte man die ja nicht (abgesehen von ARC und Mehrfachableitung natürlich).

Zitat:

Zitat von Stevie (Beitrag 1511688)

Mach halt einfach kein supports auf nen generisches interface

Ja okay, und wie soll man das sonst machen? Außerdem löst es das Problem auch nicht, dass die Adressen in der VMT auf die selbe Stelle zeigen.

Zitat:

Zitat von TiGü (Beitrag 1511670)

Und bei jeden Full Build kommt eine andere GUID bei raus? :roll:

Ja entweder das, oder sie werden in der DPROJ gecached, keine Ahnung. Da man auf Interfaces im Code aber eh nicht direkt über ein TGUID-Objekt, sondern in der Regel über den Interface-Namen zugreifen sollte, spielt das in 99,9% der Fälle keine Rolle. Für den Rest der Fälle muss man das dann halt konventionell lösen.

Zitat:

Zitat von jaenicke (Beitrag 1511682)

utomatisch generierte GUIDs würden jedenfalls nur einen Teil der Probleme lösen. Ich hatte das Thema GUIDs bei generischen Interfaces auch schon, wenn auch mit anderem Hintergrund. Mir fällt aber schlicht keine wirklich sinnvolle Lösung dafür ein. Deshalb hatte ich dazu auch keinen Featurerequest geschrieben bzw. erst einmal danach gesucht.

Jo, das ist richtig. Hast du einen Link?

Zitat:

Zitat von himitsu (Beitrag 1511681)

Es könnte auch sein, dass garkeine GUID generiert wird und die einfach nur 0000-000-00000-0000.... ist

Mir war so, als wenn der Compiler bei Interfaces "ohne" GUID eh gewisse Dinge verbietet / nicht kompilert, wie z.B. die Verwendung von IS und AS.
Somit wäre dabei die GUID dann eh egal, wenn sie nie verwendet würde.

Das ist richtig, du kannst den Interfacetypen nicht direkt als Bezeichner übergeben, falls du keine GUID definiert hast. Außerdem funktioniert "as" nicht.
Genau deshalb sind GUIDs ja so wichtig.

[jaenicke]

Zitat:

Zitat von Dennis07 (Beitrag 1511705)

Jo, das ist richtig. Hast du einen Link?

Ich weiß nicht, ob es einen solchen Featurerequest schon gibt. Aber ich wollte darauf hinaus, dass du ansonsten einen erstellen musst, damit es eine Chance auf Umsetzung gibt.

[Dennis07]

Oh ja, ich habe das k vor dem einen überlesen. :pale: Wird Zeit den Kopf zu lüften... :-D

[himitsu]

Delphi-Quellcode:

type
  IGenItf<T> = geninterface
    // Keine GUID hier (oder doch, aber egal)
    function Foo: T;
    procedure Poo;
  end;

type
  IIntItf = interface(IGenItf<Integer>)
    ['{123.......}']
  end;
  IStrItf = interface(IGenItf<String>)
    ['{456.......}']
  end;

  TImplObject = class(TInterfacedObject, IIntItf, IStrIntf)
    ...

[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;

[himitsu]

Rein syntaktisch ist das doch eigentlich falsch. :stupid:

Attribute stehen doch vor dem, was sie beschreiben und (leider) nicht dahinter.

Delphi-Quellcode:

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

  [GUID('{00000000-0000-0000-0000-000000000000}')]
  IGenItf<T> = interface
    function Foo: T;
    procedure Poo;
  end;

[freimatz]

Zitat:

Zitat von Uwe Raabe (Beitrag 1511713)

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;

Hm, wäre es nicht noch weniger invasiv, wenn Delphi immer eine intern automatisch macht, wenn man nichts angibt? (Ggf. nur bei Generics)
Oder gibt es Fälle wo man wirklich keine haben will?

[TiGü]

Na viel Spaß sobald der Erste versucht sich das über Modulgrenzen (EXE, DLL) hinweg in andere Sprachen/Framework zu übergeben und die Gegenseite eher nicht so glücklich mit dynamischen GUIDs ist.

[Uwe Raabe]

Zitat:

Zitat von TiGü (Beitrag 1511719)

Na viel Spaß sobald der Erste versucht sich das über Modulgrenzen (EXE, DLL) hinweg in andere Sprachen/Framework zu übergeben und die Gegenseite eher nicht so glücklich mit dynamischen GUIDs ist.

Deswegen sollen die ja auch nur optional sein. Insbesondere da, wo bisher gar keine stehen.

[jaenicke]

Zitat:

Zitat von TiGü (Beitrag 1511719)

Na viel Spaß sobald der Erste versucht sich das über Modulgrenzen (EXE, DLL) hinweg in andere Sprachen/Framework zu übergeben und die Gegenseite eher nicht so glücklich mit dynamischen GUIDs ist.

Die andere Seite merkt ja nichts von dynamischen GUIDs, aber egal ob bei vorkompilierten Units in der gleichen ausführbaren Datei oder DLLs oder Packages:
Solange nicht klar definiert ist, welche GUID zu welchem konkreten Typ dynamisch zugeordnet wird, klappt das ganze nicht.

Deshalb könnte ich mir nur eine im Projekt gepflegte Tabelle oder etwas ähnliches vorstellen, ähnlich dem TLB-Editor, mit speziellen Textdateien, die die Zuordnungen anhand des voll qualifizierten Typnamens, sprich inkl. Unitname, enthalten. Ich kann mir aber ehrlich gesagt nicht so recht vorstellen, dass Embarcadero ein solches Feature implementiert, wenn es nicht wirklich viele, ganz viele, Votes für einen entsprechenden Featurerequest gibt.

[himitsu]

Delphi-Quellcode:

const
  // Die Konstante kann auch aus einer gemeinsamen UNIT oder .INC kommen.
  // resourcestring anstatt const geht aber nicht, weil Konstante eine GUID und kein String sein muß.
  MyGUID: TGUID = '{BE3C619C-001C-490E-A377-C08D51E18C0C}';

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

Delphi-Quellcode:

type
  IGenItf<T> = interface
    [{$INCLUDE 'MyGUID.inc'}]    // '{BE3C619C-001C-490E-A377-C08D51E18C0C}'
    function Foo: T;
    procedure Poo;
  end;

Delphi-Quellcode:

type
  IGenItf<T> = interface
    {$INCLUDE 'MyGUID.inc'}      // ['{BE3C619C-001C-490E-A377-C08D51E18C0C}']
    function Foo: T;
    procedure Poo;
  end;

nur Nachfolgendes geht natürlich nicht

Delphi-Quellcode:

type
  IGenItf<T> = interface
    ['{$INCLUDE MyGUID.inc}']    // {BE3C619C-001C-490E-A377-C08D51E18C0C}
    function Foo: T;
    procedure Poo;
  end;

Delphi-Quellcode:

type
  IGenItf<T> = interface
    ['{{$INCLUDE MyGUID.inc}}']  // BE3C619C-001C-490E-A377-C08D51E18C0C
    function Foo: T;
    procedure Poo;
  end;

[freimatz]

Zitat:

Zitat von TiGü (Beitrag 1511719)

Na viel Spaß sobald der Erste versucht sich das über Modulgrenzen (EXE, DLL) hinweg in andere Sprachen/Framework zu übergeben und die Gegenseite eher nicht so glücklich mit dynamischen GUIDs ist.

Na ja das Problem hat man ja auch sonst, dass man sich mit der Gegenseite einig sein muss.
Bei generische interfaces über Modulgrenzen hinweg - selber Schuld wer sowas dort verwenden will.

[jaenicke]

Zitat:

Zitat von freimatz (Beitrag 1511756)

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:

Zitat von freimatz (Beitrag 1511791)

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:

Zitat von himitsu (Beitrag 1511792)

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:

Zitat von Uwe Raabe (Beitrag 1511713)

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:

Zitat von MyRealName (Beitrag 1523427)

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

Delphi-Quellcode:

IGenItf<string>

bzw.

Delphi-Quellcode:

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.