Delphi-PRAXiS
Seite 1 von 3  1 23      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Generische Interface-GUIDs (https://www.delphipraxis.net/211413-generische-interface-guids.html)

Dennis07 12. Sep 2022 12:12

Delphi-Version: 11 Alexandria

Generische Interface-GUIDs
 
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ü 12. Sep 2022 13:17

AW: Generische Interface-GUIDs
 
Und bei jeden Full Build kommt eine andere GUID bei raus? :roll:

himitsu 12. Sep 2022 14:18

AW: Generische Interface-GUIDs
 
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 12. Sep 2022 14:21

AW: Generische Interface-GUIDs
 
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 12. Sep 2022 15:00

AW: Generische Interface-GUIDs
 
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 12. Sep 2022 15:06

AW: Generische Interface-GUIDs
 
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 12. Sep 2022 15:23

AW: Generische Interface-GUIDs
 
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 12. Sep 2022 16:34

AW: Generische Interface-GUIDs
 
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 12. Sep 2022 16:47

AW: Generische Interface-GUIDs
 
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 12. Sep 2022 17:04

AW: Generische Interface-GUIDs
 
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.


Alle Zeitangaben in WEZ +1. Es ist jetzt 07:40 Uhr.
Seite 1 von 3  1 23      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz