Generisches Alias von TFrame

[himitsu]

Zitat:

Zitat von hzzm (Beitrag 1402111)

In FreePascal gaebe es ja glaube ich

Delphi-Quellcode:

TBananenKorb = specialize TObstKorb<TBanane>;

. Wie deklariere ich denn die Spezialisierung in Delphi ohne sie abzuleiten?

Keine Ahnung was das specialize in FP sein soll.

Ist das sowas wie type?

Delphi-Quellcode:

type 
  TAbc = TXyz;  // Alias
  TAbc = type TXyz;  // neuer Typ / eigene RTTI <<<<<<<<

  TAbc = class(TXyz);  // Ableitung/Vererbung

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1402141)

Zitat:

Zitat von hzzm (Beitrag 1402111)

In FreePascal gaebe es ja glaube ich

Delphi-Quellcode:

TBananenKorb = specialize TObstKorb<TBanane>;

. Wie deklariere ich denn die Spezialisierung in Delphi ohne sie abzuleiten?

Keine Ahnung was das specialize in FP sein soll.

Specialize ist die "pascalishe" Syntax für Generics, die sich die FPC devs ausgedacht haben - einfach mal in die Doku schauen: http://wiki.freepascal.org/Generics

Hat aber kaum mit dem Problem hier zu tun, dass abhängig von einem Typen von T eine abstrakte Methode plötzlich was ausführen könnte. Polymorphie hat in dem Zusammenhang nix mit Generics zu tun.

Generics sind prinzipiell dafür da, ebend unabhängig vom Typen einen Algorithmus auszuführen und nicht kontextuell etwas anderes (wenn T Banane ist, das, wenn es es Apfel ist, etwas anderes).

Allerdings kann man sofern man eh schon einen constaint (

Delphi-Quellcode:

TProgrammModel<T: TFrucht>

) hat mit einfachen Mitteln prüfen:

Delphi-Quellcode:

constructor TProgrammModel<T>.Create;
begin
  if TypeInfo(T) = TypeInfo(TBanane) then
    fKorb := TKorb<T>(TBananenKorb.Create)
  else if TypeInfo(T) = TypeInfo(TApfel) then
    fKorb := TKorb<T>(TApfelKorb.Create);
end;

[hzzm]

Zitat:

Zitat von Stevie (Beitrag 1402149)

Generics sind prinzipiell dafür da, ebend unabhängig vom Typen einen Algorithmus auszuführen und nicht kontextuell etwas anderes

Das trifft ja ziemlich genau meine letzte allgemeine Problem-Beschreibung:
Ich benoetige ein Objekt, das entweder ein TApfel (/A1) oder eine TBanane (/A2) sein kann und will darauf unabhaengig vom Typ meine allgemeinen Algorithmen ausfuehren (A-manipulierend, A-Rausgebend Getter etc.) eben ohne explizit alles in TApfel- und TBanane-Prozeduren (separate private TBanane und TApfel im Adapter) spalten zu muessen.

Also vermute ich mal, dass ich zu Recht zu generics gegriffen habe.
Das Problem ist nur, dass ich meinen Adapter, mein Model und alles was in Abhaengigkeit (oder eher Unabhaengigkeit) von TApfel oder TBanane handeln will, natuerlich auch Generisch deklarieren moechte. Denn dann erstelle ich mir auf oberster Ebene festlegend einfach einen

Delphi-Quellcode:

ObstAdapter := TObstAdapter<TBanane>.Create;

oder eben

Delphi-Quellcode:

TObstAdapter<TApfel>.Create;

, der wiederum entsprechend entweder einen TApfel oder eine TBanane in sich erstellt usw.

In Wirklichkeit sind da noch ein paar generisch abhaengige Ebenen dazwischen, aber wenn eine geht, gehen alle. Hauptsache nicht alles ausschreiben oder immer um <T> rumanalysieren (wobei die Loesung von Stevie noch einigermassen ertraeglich scheint). Das war meine Erwartung, das <T> einfach runterreichen zu koennen...

[himitsu]

Zitat:

Zitat von Stevie (Beitrag 1402149)

Specialize ist die "pascalishe" Syntax für Generics, die sich die FPC devs ausgedacht haben - einfach mal in die Doku schauen: http://wiki.freepascal.org/Generics

Nja, was sagt denn der ClassName von TBananenKorb?

Delphi-Quellcode:

uses
  TypInfo,
  Generics.Collections;

type
  TTest1 = TList<Integer>;
//TTest2 = type TList<Integer>;  // [DCC Fehler] E2574 Instantiierter Typ kann nicht für TYPE-Typdeklaration verwendet werden
  TTest2 = type TList;
//TTest3 = specialize TList<Integer>;
  TTest4 = class(TList<Integer>);

procedure TForm1.FormCreate(Sender: TObject);
begin
  ShowMessage('TypeName + ClassName + ParentClassName = Type<>SourceType' + sLineBreak
    + PTypeInfo(TypeInfo(TTest1)).Name + ' + ' + TTest1.ClassName + ' + ' + TTest1.ClassParent.ClassName + ' = ' + BoolToStr(TypeInfo(TTest1) = TypeInfo(TList<Integer>), True) + #10
    + PTypeInfo(TypeInfo(TTest2)).Name + ' + ' + TTest2.ClassName + ' + ' + TTest2.ClassParent.ClassName + ' = ' + BoolToStr(TypeInfo(TTest2) = TypeInfo(TList{<Integer>}), True) + #10
  //+ PTypeInfo(TypeInfo(TTest3)).Name + ' + ' + TTest3.ClassName + ' + ' + TTest3.ClassParent.ClassName + ' = ' + BoolToStr(TypeInfo(TTest3) = TypeInfo(TList<Integer>), True) + #10
    + PTypeInfo(TypeInfo(TTest4)).Name + ' + ' + TTest4.ClassName + ' + ' + TTest4.ClassParent.ClassName + ' = ' + BoolToStr(TypeInfo(TTest4) = TypeInfo(TList<Integer>), True));

  // TypeName + ClassName + ParentClassName = Type<>SourceType
  // TList<System.Integer> + TList<System.Integer> + TEnumerable<System.Integer> = True
  // TTest2 + TList + TObject = False
  // TTest4 + TTest4 + TList<System.Integer> = False
end;

Code:

TypeName               + ClassName              + ParentClassName              = Type<>SourceType

TList<System.Integer> + TList<System.Integer> + TEnumerable<System.Integer> = True
TTest2                + TList<System.Integer> + TEnumerable<System.Integer> = False   (wenn es mit TList<> gegangen wäre)
TTest3 ?
TTest4                + TTest4                + TList<System.Integer>        = False

[himitsu]

Delphi-Quellcode:

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

  TKanne<T1> = TSpeziellerFrame<T1>;

Hab mal das T unterschiedlich benann, als T1 und T2, damit man besser sieht, was direkt zusammen hängt.

Zitat:

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

Wegen dem Semikolon?

Oder was soll da nicht gehn?
Es wäre bestimmt hilfreich, wenn jemand (ich schau jetzt mal niemanden speziellen an) bei sowas die Fehlermeldung kopieren würde. :stupid:


PS: Vom Verständnis her, macht es sich IMHO ungünstig, wenn bei

Delphi-Quellcode:

type TIrgendwas<Bezeichner> = ...;

der "Bezeichner" genau wie ein "existierendet" Typ/Klasse benannt wird ... Verwechslungsgefahr.

[hzzm]

Zitat:

Zitat von himitsu (Beitrag 1402176)

Es wäre bestimmt hilfreich, wenn jemand (ich schau jetzt mal niemanden speziellen an) bei sowas die Fehlermeldung kopieren würde. :stupid:

Der Semikolon-Fehler war nur im Beispiel, ich habe den Code leider schon laenger nicht mehr so drin.

Ich hab jetzt alles nochmal 10x hin- und hergedreht und denke einfach, ich muss einen Strukturfehler bei den generischen Definitionen machen.
Das kann doch nicht sein, dass das nicht geht. Ich nehme noch einen Anlauf und versuche, meine Struktur zwar simpel, aber so genau wie moeglich darzustellen.

Vielen Dank auf jeden Fall schonmal fuer Eurer aller Bemuehungen!

Delphi-Quellcode:

unit Schritt;

interface

uses
  Zugabe, SysUtils, CleanFloats;

type
  PSchritt = ^TSchritt;
  TSchritt = class
    Temperatur,
    Zeit,
    Gewicht: String[5];

    Zugaben: TZugaben;
  public
    procedure WriteToStream(Offset: Word); virtual; abstract;
    procedure ReadFromStream(Offset: Word); virtual; abstract;
  End;
  TSchritte = TArray<TSchritt>;

  PKSchritt = ^TKSchritt;
  TKSchritt = class(TSchritt)
    Breite,
    Wasser: String[5];
  public
    procedure WriteToStream(Offset: Word); override;
    procedure ReadFromStream(Offset: Word); override;
  End;
  TKSchritte = TArray<TKSchritt>;

  PMSchritt = ^TMSchritt;
  TMSchritt = class(TSchritt)
    Viskositaet,
    Intervall: String[5];
  public
    procedure WriteToStream(Offset: Word); override;
    procedure ReadFromStream(Offset: Word); override;
  End;
  TMSchritte = TArray<TMSchritt>;
  
  
  TZugabe = packed Record
    Name: String[40];
    Menge: String[5];
    Einheit: String[5];
  end;
  TZugaben = TArray<TZugabe>;

Delphi-Quellcode:

unit Rezept;

interface

uses
  Schritt, Zugabe, Hashes;

type
  TRezept<T: TSchritt> = class
    Dateiname: String[70];
    Name,
    Gruppe,
    Datum: String[40];
    Schritte: TArray<T>;
    procedure SchrittLoeschen(const Index: Integer);
    procedure ReadCSV(Dateiname: String); virtual; abstract;
    procedure WriteCSV(Dateiname: String); virtual; abstract;
    procedure LeereSchritt(var Index: Integer); virtual; abstract;
  End;

  PKRezept = ^TKRezept;
  TKRezept = class(TRezept<TKSchritt>)
    procedure ReadCSV(Dateiname: String); override;
    procedure WriteCSV(Dateiname: String); override;
    procedure LeereSchritt(var Index: Integer); override;
  End;

  PMRezept = ^TMRezept;
  TMRezept = class(TRezept<TMSchritt>)
    procedure ReadCSV(Dateiname: String); override;
    procedure WriteCSV(Dateiname: String); override;
    procedure LeereSchritt(var Index: Integer); override;
  End;

Delphi-Quellcode:

unit Programm;

interface

uses
  SysUtils, ExtCtrls, Rezept, Schritt, Vcl.Forms, Observer, KProgrammView, MProgrammView;

type
  TProgrammModel<T: TSchritt> = class
  public
    Rezept: TRezept<T>;
//    Rezept: TKRezept;  // So geht es, generisch nicht!
    constructor Create{(AOwner: TComponent)};
  End;

  TProgrammAdapter<T: TSchritt> = class(TInterfacedObject, IProgrammAdapter)
  private
    Model: TProgrammModel<T>;
    IView: IProgrammView;
  public
    Notifier: TObserverSubject;
    constructor Create(AOwner: TComponent; IAView: IProgrammView; AModel: TProgrammModel<T>);
    procedure WriteToStream(Sender: TObject);
    procedure ReadCSV(Filename: String);
    procedure ScaleIngredients(Percent: Integer);
    function GetRecipeName: String;
    function GetRecipeFilename: String;
    procedure SetRecipe(ARezept: TRezept<T>);
  End;
  
implementation

constructor TProgrammAdapter<T>.Create(AOwner: TComponent; IAView: IProgrammView; AModel: TProgrammModel<T>);
begin
  IView := IAView;
  Steps := IView.GetSteps;
  Model := AModel;
end;

procedure TProgrammAdapter<T>.ReadCSV(Filename: String);
begin
//  if Model.Rezept <> nil then
//    Model.Rezept.Free;
//  if TypeInfo(T) = TypeInfo(TKSchritt) then
//    Model.Rezept := TRezept<TKSchritt>.Create
//  else if TypeInfo(T) = TypeInfo(TMSchritt) then
//    Model.Rezept := TRezept<TMSchritt>.Create;

  Model.Rezept.ReadCSV(Filename); // Abstrakter Fehler!
end;

[Stevie]

Zitat:

Zitat von hzzm (Beitrag 1402195)

Delphi-Quellcode:

unit Rezept;

interface

uses
  Schritt, Zugabe, Hashes;

type
  TRezept<T: TSchritt> = class
    Dateiname: String[70];
    Name,
    Gruppe,
    Datum: String[40];
    Schritte: TArray<T>;
    procedure SchrittLoeschen(const Index: Integer);
    procedure ReadCSV(Dateiname: String); virtual; abstract;
    procedure WriteCSV(Dateiname: String); virtual; abstract;
    procedure LeereSchritt(var Index: Integer); virtual; abstract;
  End;

  PKRezept = ^TKRezept;
  TKRezept = class(TRezept<TKSchritt>)
    procedure ReadCSV(Dateiname: String); override;
    procedure WriteCSV(Dateiname: String); override;
    procedure LeereSchritt(var Index: Integer); override;
  End;

  PMRezept = ^TMRezept;
  TMRezept = class(TRezept<TMSchritt>)
    procedure ReadCSV(Dateiname: String); override;
    procedure WriteCSV(Dateiname: String); override;
    procedure LeereSchritt(var Index: Integer); override;
  End;

Zitat:

Zitat von Stevie (Beitrag 1402149)

Hat aber kaum mit dem Problem hier zu tun, dass abhängig von einem Typen von T eine abstrakte Methode plötzlich was ausführen könnte. Polymorphie hat in dem Zusammenhang nix mit Generics zu tun.

Ich seh in dem Code nich die Stelle, wo du die Rezept Instanz erstellst, aber gemäß dieser Unit oben bist du dort nicht mehr generisch, sondern leitest von einer generischen Spezialisierung ab, da die generische Klasse nunmal abstrakte Methoden hat - deshalb habe ich meinen Satz von vorher hier nochmal zitiert.

[hzzm]

Zitat:

Zitat von Stevie (Beitrag 1402245)

Ich seh in dem Code nich die Stelle, wo du die Rezept Instanz erstellst, aber gemäß dieser Unit oben bist du dort nicht mehr generisch, sondern leitest von einer generischen Spezialisierung ab, da die generische Klasse nunmal abstrakte Methoden hat - deshalb habe ich meinen Satz von vorher hier nochmal zitiert.

Verstehe.
Gemaess meinem Kommentar im Code

Delphi-Quellcode:

// Rezept: TKRezept; // So geht es, generisch nicht!

, kann ich das Model.Rezept als TKRezept deklarieren und mit

Delphi-Quellcode:

TKRezept.Create;

initialisieren, dann funktioniert natuerlich alles (solange der ProgrammAdapter als TProgrammAdapter<TKSchritt> erstellt wird).

Aber das widerspricht ja dem Zweck dieser generischen Struktur, ich will ja auch das Rezept in generischer Abhaengigkeit vom Rest erstellen. Genau das ist der Punkt, an dem ich scheitere; wenn ich im Model 2 Variationen,

Delphi-Quellcode:

KRezept: TKRezept;

und

Delphi-Quellcode:

MRezept: TMRezept;

ablegen muss, die ich konditional bestelle, bin ich ja in genau meiner Zwickmuehle, dass ich viel code zwiespalten muss, obwohl er eigentlich gleich ist. Eine meiner Anfangs-Motivationen zu generics zu greifen.

Gibt es zu diesem Problem innerhalb der Delphi generics ueberhaupt eine Loesung?

Delphi-Quellcode:

constructor TProgrammModel<T>.Create;
begin
  // Rezept := TKRezept.Create; // geht (Deklaration auch als Rezept: TKRezept;)
  // Rezept := TKRezept.Create; // scheitert bei Deklaration als Rezept: TRezept<T>; natuerlich
  Rezept := TRezept<T>.Create; // geht wie besprochen nicht: Abstrakte Fehler
end;

[freimatz]

Nein, innerhalb der Delphi Generics nicht. Dazu ist dann die Polymorphie da.

[Stevie]

Irgendwo in der Struktur muss ein Teil rein, was anhand des konkreten Typs von T die richtige nicht generische Klasse zum Lesen/Speichern/Whatever erstellt, sofern dieser Code nicht über einen generischen Algo gelöst werden kann. Ich würde mir also überlegen, das CSV Zeugs nicht per Ableitung sondern Aggregation zu koppeln.

Ja, irgendwo im generischen Code muss dann eine if-then-else "Leiter" wie zuvor schon gezeigt rein.

Die Aggregation kann dann per API die Basisklasse nutzen aber je nach Implementierung weiß sie dann, dass die TFrucht Instanzen, die da rein oder raus gehen Äpfel oder Bananen sind.

Aus Erfahrung würd ich dir raten, das Design nochmal zu überdenken und genau zu schauen, wo du strikte Typensicherheit haben willst und wo du lieber mit einer nicht generischen Basisklasse arbeitest die auf Instanzen von TSchritt arbeiten. Man kann dann auch problemlos eine sehr dünne generische Schicht auf eine solche nicht generische Klasse oben drauf setzen (oder per Interface implementieren), so dass entsprechende Consumer typensicher arbeiten. Tiefe generische Hierarchien, bei denen dann noch die Logik abhängig vom generischen Typenparameter ist, enden selten gut.