Generisches Alias von TFrame

[hzzm]

Tut mir leid, dass ich Euch schon wieder belaestigen muss.
Ich haenge an etwas so simplem, aber die Loesung ist nicht greifbar:

Ich versuche ganz einfach ein generisches Alias fuer einen Frame zu deklarieren.
Nach einiger googlerei denke ich, dass ich einfach die "CreateNew" statt "Create" wie bei TForm fuer TFrame suche.
Aber mal ganz von vorne:

Delphi-Quellcode:

type
  TSpeziellerFrame = class(TFrame)
    [...]
  End;

  TKanne<TObjectList> = class( TSpeziellerFrame; ) // ohne class() kompilierts gar nicht

Delphi-Quellcode:

constructor TJodokus<T>.Create(AOwner: TComponent);
var
  AView: TKanne<T>;
begin
  AView := TKanne<T>.Create(AOwner); // hier krachts: TCustomFrame.Create-> not InitInheritedComponent(Self, TFrame) -> raise EResNotFound
end;

Delphi-Quellcode:

begin
  TJodokus<TObjectList>.Create(Self);
end;

Gibt es irgendeinen legitimen Grund, warum das nicht von Natur aus funktioniert?!
Habe schon etliche Konstellationen probiert, komme aber einfach nicht drauf.
Danke fuers Lesen!

[Rollo62]

Warum das nicht läuft habe ich jetzt nicht gecheckt, aber
wäre nicht ein Interface das was du suchst statt die Klasse selbst zu speichern ?

Delphi-Quellcode:

type
  TSpeziellerFrame = class(TFrame, ISpeziellerFrame)
    [...]
  End;

Rollo

[himitsu]

Zitat:

ohne class() kompilierts gar nicht

Natürlich nicht, denn du willst ja einen neuen generischen Typen definieren, also muß das auch als eigenständiger Typ (neue Klassendefinition) deklatiert werden.

"Einen" Alias für mehrere Klassen kannst du so eh nicht definieren.

Ob sowas type TKanne<xxx> = TSpeziellerFrame<xxx>; geht, also wirklich ein Alias, weiß ich jetzt nicht, oder ob man da auch type TKanne<xxx> = class(TSpeziellerFrame<xxx>); machen muß.


Dieser Alias TKanne = TSpeziellerFrame<TObjectList>; geht allerdings, aber wenn man sowas als Komponente/SubKomponente in der DFM speichern will, also auf den Formdesigner legen,
dann darf es kein Alias sein, sondern muß als neuer Typ TKanne = class(TSpeziellerFrame<TObjectList>); verpackt werden, da gültige "Bezeichner" für die Klassenverwaltung und den DFM-Reader keine < und > enthalten dürfen.

[hzzm]

Ok, vielen Dank!

So langsam gehen mir die Delphi-Generics auf den Keks, alles muss man nachher trotzdem manuell aufbroeseln. Da kann ich auch direkt alles ausschreiben, wenns immer an exakt den Ecken haengenbleibt, an denen Generics den Code vereinfachen/verallgemeinern wuerden... vielleicht habe ich da auch nur generell eine falsche Erwartungshaltung bzgl. generics, aber ich dachte das aus anderen OO-Sprachen etwas flexibler zu kennen.

[Zacherl]

Zitat von hzzm:

So langsam gehen mir die Delphi-Generics auf den Keks, alles muss man nachher trotzdem manuell aufbroeseln. Da kann ich auch direkt alles ausschreiben, wenns immer an exakt den Ecken haengenbleibt, an denen Generics den Code vereinfachen/verallgemeinern wuerden... vielleicht habe ich da auch nur generell eine falsche Erwartungshaltung bzgl. generics, aber ich dachte das aus anderen OO-Sprachen etwas flexibler zu kennen.

Ja, die Delphi Generics sind tatsächlich nur begrenzt nützlich und in keinem Fall mit anderen Sprachen vergleichbar. Das liegt primär daran, dass der Compiler deine Funktionen IMMER generiert und zwar so, dass sie theoretisch für jeden Typ lauffähig wären. Dadurch muss man sehr viel mit RTTI, "schwarzer Magie" und unsicheren Casts arbeiten. Bei anderen Sprachen wie C++ z.B. wird zur Compile-Time geschaut mit welchen Typen eine generische Funktion überhaupt aufgerufen wird und nur diese entsprechenden Varianten werden dann auch erzeugt. Im Zusammenspiel mit Template Spezialisierungen benötigt man dann absolut keine zusätzliche Laufzeitbehandlung.

Sowas wünsche ich mir für Delphi ja nach wie vor, aber ich befürchte dass wird ein Wunschtraum bleiben.

[hzzm]

Warum meckert er denn hier schon wieder:

Delphi-Quellcode:

type
  TObstKorb<T: TFrucht> = class
    procedure Essen; virtual; abstract;
  End;

  TBananenKorb = class(TObstKorb<TBanane>)
    procedure Essen; override;
  End;

[...]
begin
  AKorb := TObstKorb<TBanane>.Create;
  AKorb.Essen; // abstrakter Fehler

  AKorb := TBananenKorb.Create;
  AKorb.Essen; // funktioniert
end;

In FreePascal gaebe es ja glaube ich TBananenKorb = specialize TObstKorb<TBanane>; . Wie deklariere ich denn die Spezialisierung in Delphi ohne sie abzuleiten?

[freimatz]

Er meckert weil AKorb ein TObstKorb<TBanane> ist und dort ist Essen abstract. Ich würde da einen Fehler erwarten.

Wozu willst du eine Spezialisierung? Ich leite immer ab wenn ich es brauche.

So ganz kann ich Deine Probleme leider nicht nachvollziehen. Mich nerven die zwar auch, ab an anderen Stellen wie z.b., dass es keine contraints für Aufzählungstypen gibt.
Wie verwenden gerne Generics (gerade gesucht - an insgesammt 2168 Stellen)

[hzzm]

Zitat von freimatz:

Wozu willst du eine Spezialisierung? Ich leite immer ab wenn ich es brauche.

Wenn TObstKorb<TBanane>.Create funktionieren wuerde, koennte ich in einer generischen Funktion in Abhaengigkeit von T a la

Delphi-Quellcode:

constructor TProgrammModel<T>.Create;
begin
  Data := TObstKorb<T>.Create;
end;

die Generik weiterreichen. Das waere doch praktisch, oder?
So wie es aussieht, muss ich aber in jeder generischen Ebene dann so einen Schei*dreck wie

Delphi-Quellcode:

constructor TProgrammModel<T>.Create;
var
  AInfo: PTypeInfo;
  AInfoData: PTypeData;
  tkString: String;
begin
  AInfo := System.TypeInfo(T);
  AInfoData := GetTypeData(AInfo);
  tkString := TypInfo.GetEnumName(System.TypeInfo(T), Ord(AInfoData^.OrdType));

  if tkString = 'tkBanane' then
    AKorb := TBanenenKorb.Create
  else if tkString = 'tkApfel' then
    AKorb := TApfelKorb.Create;
end;

machen.
Erst so kann ich AKorb<T: TFrucht> wirklich generisch verwenden?! Und das in jeder generischen Hierarchie-Ebene?
JESUS CHRIST, please kill me.

Oder uebersehe ich da jetzt massiv was...

[freimatz]

Oder ich...
Ich wüsste jetzt woher der compiler wissen soll dass Du nicht TObstKorb<TBanane> sondern TBananenKorb haben willst.
Vielleicht vergisst Du mal die Generics und beschreibst mal welches Anwender-Problem Du lösen willst.

[hzzm]

Zitat von freimatz:

Vielleicht vergisst Du mal die Generics und beschreibst mal welches Anwender-Problem Du lösen willst.

Nachdem ich meine Struktur nun wieder ein ganzes Stueck von generics weggebracht habe, versuche ich mal mein Problem grundsaetzlich und vereinfacht zu beschreiben:

Ich habe 2 Objekt-Typen (nennen wir die Typen mal A1 und A2), die ein paar gleiche und ein paar unterschiedliche Variablen und Funktionen besitzt.
Daher erben sie die allgemeinen Eigenschaften vom Typ A.
Die Eigenschaften, die gleich sind (von A geerbt), werden von vielen anderen Units im Programm benoetigt und manipuliert.
Das ganze Programm verwendet insgesamt nur entweder A1 oder A2, nie beide Typen.

Ich habe ein Adapter-Objekt, das die meisten Manipulationen (sowohl Typ A, A1 und A2) daran vornimmt. Die anderen Units benoetigen immer nur Typ A allgemein, nie die Eigenschaften von A1 und A2.

Daher hat mein Adapter einen Getter, der Typ A rausgibt, aber auch viele andere Getter, die einzelne A-Eigenschaften an andere Units rausgeben.

Ich will vermeiden, dass ich 2 unterschiedliche A1 A2 im Adapter ablege, sprich vermeiden, dass ich alle Getter/Setter/etc des Adapters zwiespalten muss, obwohl nahezu identischer Code ausgefuehrt wird.