Von TObjectList<T> erben?

[ryLIX]

Ich würde gerne meine angepasste Objektliste auf Generics umstellen.
Nur ich frag mich schon die ganze Zeit wie nun die Klassendefinition aussehen muss.

Delphi-Quellcode:

TNonFoodList = class(TObjectList<TNonFood>)
TNonFoodList<T: TNonFood> = class(TObjectList<TNonFood>) //Gesehen bei StackOverflow
TNonFoodList<TNonFood> = class(TObjectList<T: class>)

Es müsste doch eigentlich die letzte Variante sein oder?
Da TObjectList<T> so definiert ist:

Delphi-Quellcode:

TObjectList<T: class> = class(TList<T>)

:gruebel: :gruebel:

[m.wollert]

Hi,

für das was Du vermutlich anstellen willst, ist die Variante 1 die Richtige.

Ich gehe davon aus, dass Du eine verwaltete Liste mit Objekten vom Typ TNonFood erstellen möchtest.

Grüße
Michael

[ryLIX]

Ja richtig erkannt es soll vom Typ TNonFood sein.
Is mir irgendwie entfallen das zu erwähnen :roll:

Danke für die Hilfe ich werds nachher mal probieren.

Edit:

Delphi-Quellcode:

TNonFoodList = class(TObjectList<TNonFood>)

Ergibt:

Zitat:

[DCC Fehler] WarenContainerGenerisch.pas(12): E2003 Undeklarierter Bezeichner: 'TObjectList<>'

:?

[Khabarakh]

Generics.Collections hast du aber schon geöffnet?

PS: Bei Listen ist Vererbung unüblich, eine Komposition ist oft einfacher.

[ryLIX]

Zitat:

Zitat von Khabarakh

Generics.Collections hast du aber schon geöffnet?

PS: Bei Listen ist Vererbung unüblich, eine Komposition ist oft einfacher.

Grbl das wars -.-
Jetzt compilliert es schon mal :D
Getestet hab ich aber noch nicht.

Was meinst du mit Komposition?
Im Moment bin ich bei der Umstellung auf Generics eh am überlegen ob eventuell ein TDictionary<TValue, TKey> nicht besser ist.
:roll:
Eigentlich herrscht über die Generics bei mir grosse Verwirrung :?

[himitsu]

[quote="ryLIX"]

Zitat:

Zitat von Khabarakh

Generics.Collections hast du aber schon geöffnet?

Das "Blöde" an der Generics-Unit ist, daß da irgendwer auf eine total bescheuerte Idee gekommen ist
und die generischen Klassen genauso benannt hat, wie die Normalen.
Somit kommt es zu solchen blöden Namenspoblemen und irreführenden Fehlermeldungen.

[Uwe Raabe]

Zitat:

Zitat von Khabarakh

PS: Bei Listen ist Vererbung unüblich, eine Komposition ist oft einfacher.

In diesem Fall handelt es sich aber nicht um klassische Vererbung, sondern um die Instanziierung(Typisierung?) eines generischen Typs.

Es ist z.B. auch nicht möglich, eine Variable eines generischen Typs zu deklarieren (außer als Feld in einer generische Klasse):

Delphi-Quellcode:

var
  List: TObjectList<T>;

läßt sich nicht compilieren.

Damit scheidet eine Komposition schon mal aus.

Man muss sich Generics einfach als Klassen-Vorlagen vorstellen. Erst durch die Bestimmung des oder der variablen Typen wird daraus eine verwendbare herkömmliche Klasse. Mit

Delphi-Quellcode:

type
  TNonFoodList = class(TObjectList<TNonFoodList>);

wird implizit eine Klassendeklaration erstellt, bei der alle "T" in TObjectList<T> durch TNonFood ersetzt werden.

[himitsu]

Zitat:

Zitat von Uwe Raabe

Delphi-Quellcode:

var
  List: TObjectList<T>;

läßt sich nicht compilieren.

Und mit welcher Fehlermeldung?

Sowas läßt sich z.B. bei mir compilieren:

Delphi-Quellcode:

var
  List: TObjectList<TEdit>;

Zitat:

Zitat von Uwe Raabe

Man muss sich Generics einfach als Klassen-Vorlagen vorstellen. Erst durch die Bestimmung des oder der variablen Typen wird daraus eine verwendbare herkömmliche Klasse.

Jupp, es wird praktisch beim Compilieren eine Kopie dieser Vorlage erstellt, die angegebenen Typen darin ersetzt und dann alles als eigenständiger Code kompiliert.
(es sei denn es wurde vorher schonmal eine gleichartige Typ-Kombination für diesem Generic kompiliert, dann wird diese natürlich wiederverwendet)

Dieses würde alle nötigen Codes doppelt in die Anwendung reinkompiliert ... einmal alles mit TEdit und dann nochmal alles mit TButton:
Es wäre praktisch so, als wenn man zwei Objektlisten im QuellCode "parallel" erstellt hätte.

Delphi-Quellcode:

var
  ListA: TObjectList<TEdit>;
  ListB: TObjectList<TButton>;

[Uwe Raabe]

Zitat:

Zitat von himitsu

Zitat:

Zitat von Uwe Raabe

Delphi-Quellcode:

var
  List: TObjectList<T>;

läßt sich nicht compilieren.

Und mit welcher Fehlermeldung?

[DCC Fehler] Unit12.pas(43): E2003 Undeklarierter Bezeichner: 'T'

Zitat:

Zitat von himitsu

Sowas läßt sich z.B. bei mir compilieren:

Delphi-Quellcode:

var
  List: TObjectList<TEdit>;

Bei mir natürlich auch. Mit der Angabe von TEdit wird ja auch das "generische" aus dem Typ aufgelöst. Das unterstreicht meine Aussage, das man keine Variablen vom Typ eines Generics deklarieren kann (bis auf die besagte Ausnahme).

[himitsu]

Achso ja, wenn du eine Variable deklarierst, dann müssen natürlich auch alle Typen aufgelöst werden,
denn "T" kennt der Compiler "zufällig" nicht und an dieser Stelle möchte er ja gern die Klasse erstellen, wofür er nunmal der fertig/vollständig deklarierten Typ benötigt ... z.B. für die spätere Speicherverwaltung und Dergleichen.

Witzig wäre es für dich geworden, wenn rein zufällig irgendein Typ mit dem Namen "T" an dieser Stelle existiert hätte. :lol:

[Uwe Raabe]

Zitat:

Zitat von himitsu

Witzig wäre es für dich geworden, wenn rein zufällig irgendein Typ mit dem Namen "T" an dieser Stelle existiert hätte. :lol:

Sollte das mal vorkommen, werde ich dir eine Karte aus der Klapsmühle schreiben...

[Panthrax]

Zitat:

Zitat von himitsu

Das "Blöde" an der Generics-Unit ist, daß da irgendwer auf eine total bescheuerte Idee gekommen ist
und die generischen Klassen genauso benannt hat, wie die Normalen.
Somit kommt es zu solchen blöden Namenspoblemen und irreführenden Fehlermeldungen.

Das ist ganz und gar nicht blöd. Bei überladenen Routinen und Methoden kommt auch jeder klar, wenn er sich einmal die Signaturen dazu ansieht:

Delphi-Quellcode:

procedure Überladen; overload; // "Überladen()"
procedure Überladen(const Wert: Integer); overload; // "Überladen(Integer)"

Bei Typen funktioniert es gleichermaßen:

Delphi-Quellcode:

TObjectList = class { ... } end; // "TObjectList()"
TObjectList<T> = class { ... } end; // "TObjectList(Typ)"

Gerade das macht es so einfach, und man muss sich nicht so viele Bezeichner merken.

[Khabarakh]

Zitat:

Zitat von himitsu

Das "Blöde" an der Generics-Unit ist, daß da irgendwer auf eine total bescheuerte Idee gekommen ist
und die generischen Klassen genauso benannt hat, wie die Normalen.

Tja, die alten Namen passen eben einfach perfekt, alternative will ich mir gar nicht vorstellen :zwinker: .
/add: Und Panthrax muss ich auch recht geben, ist imo eher eine Vereinfachung als potentielle Verwirrung.

Zitat:

Zitat von Uwe Raabe

In diesem Fall handelt es sich aber nicht um klassische Vererbung, sondern um die Instanziierung(Typisierung?) eines generischen Typs.

Nö. Sobald ein class vorkommt, ist das ganz normale Vererbung. Innerhalb des class wird in der Tat ein generischer Typ instanziert, aber dafür braucht man keine Vererbung, es genügt ein Alias:

Delphi-Quellcode:

type TNonFoodList = TObjectList<TNonFood>;

Solange wir aber nicht über TList<TDictionary<... reden, ist das aber ebenfalls unüblich, man sollte im Code einfach direkt TObjectList<TNonFood> verwenden.

Zitat:

Zitat von himitsu

Es wäre praktisch so, als wenn man zwei Objektlisten im QuellCode "parallel" erstellt hätte.

Ich gehe stark davon aus, dass es wie beim .NET-Jitter gelöst wurde: Für jeden Value Type jeweils eine Kopie, für alle Reference Types (wahrscheinlich nur alle Klassentypen) eine Kopie zusammen.

Zitat:

Zitat von Uwe Raabe

Das unterstreicht meine Aussage, das man keine Variablen vom Typ eines Generics deklarieren kann (bis auf die besagte Ausnahme).

Anders ausgedrückt: Um einen offenen generischen Typ zu verwenden, muss er geschlossen, also alle formalen Typparameter durch konkrete Typen oder Typparameter der umgegebenden Klasse/Methode ersetzt werden.

[implementation]

Also unter FPC werden Generics so spezialisiert:

Delphi-Quellcode:

type
  TNonFoodList = specialize TList<TNonFood>;

Es wundert mich wirklich, dass das unter Delphi vollkommen anders aussieht.

[himitsu]

Zitat:

Zitat von implementation

Es wundert mich wirklich, dass das unter Delphi vollkommen anders aussieht.

Eventuell hatte man es nicht hinbekommen dem Compiler ohne ein Keyword wie "specialize" beizubringen, daß gleich ein generischer Typ kommt?

in C ist es auch nicht nötig:
http://msdn.microsoft.com/en-us/magazine/cc163754.aspx

[Khabarakh]

Zitat:

Zitat von implementation

Es wundert mich wirklich, dass das unter Delphi vollkommen anders aussieht.

Weil für quasi jedes neuere Sprachfeature und jede neuere API C#/Java Pate standen und sich für FPC wahrscheinlich überhaupt niemand interessiert hat ;) . Wüsste wirklich nicht, warum man so ein vollkommen überflüssiges Keyword einführen sollte; in C# würde mich das jedenfalls in den Wahnsinn treiben, wenn ich jeden Typ explizit instanzieren müsste.

[implementation]

Hab grad mal auf FreePascal.org nachgeschlagen - die Syntax hat sich mal wieder geändert.
Jetzt geht's angeblich auch so: (noch nicht getestet)

Delphi-Quellcode:

// tom proposal:
type
  TNonFoodList = TObjectList<TNonFood>;

// dannym proposal
type
  TNonFoodList = TObjectList of TNonFood;

// plugwash:
type
  TNonFoodList = TObjectList[TNonFood];

Und so 'nen PublicJoke-Proposal mit generischen Units gibt's auch noch. :shock:
Da steigt doch kein Mensch mehr durch...

[ADD]
Die ham sogar generische Routinen eingeführt - sowas hab ich noch nie gesehen

[himitsu]

Zitat:

Zitat von implementation

Da steigt doch kein Mensch mehr durch...

Ja, ist voll toll, wenn es jetzt jeder anders machen kann und keiner mehr den Code des Anderen versteht. :-D

http://wiki.freepascal.org/Generics

[Panthrax]

Zitat:

Zitat von himitsu

Eventuell hatte man es nicht hinbekommen dem Compiler ohne ein Keyword wie "specialize" beizubringen, daß gleich ein generischer Typ kommt?

FPC war einfach schneller bei der Sprachweiterung, und man hatte sich einfach etwas überlegen müssen... Man hatte sich eben für das Schlüsselwort "specialize" entschieden.

Zitat:

Zitat von implementation

Die ham sogar generische Routinen eingeführt - sowas hab ich noch nie gesehen

Hm!?

Delphi-Quellcode:

class procedure Generics.Collections.TArray.Sort<T>(...);

[implementation]

Ne, so:

Delphi-Quellcode:

function generic(T) Max(A, B: T): T;
 begin
   if A < B then
     Result := B
   else
     Result := A;
 end;

Ziemlich am Ende der Wiki-Seite steht aber was davon, es würde bisher nur eine Notlösung für Generics laufen. Also wer weiß, ob das wirklich schon alles klappt...

[ADD]
Grad getestet, läuft noch nicht.
Sind alles nur Zukunftspläne, die da auf der Wikiseite stehen.

[himitsu]

Zitat:

Zitat von Panthrax

FPC war einfach schneller bei der Sprachweiterung, und man hatte sich einfach etwas überlegen müssen... Man hatte sich eben für das Schlüsselwort "specialize" entschieden.

OK, das wäre auch eine Erklärung, wobei man sich da ja auch nach C# hätte richten können
(oder kam das auch später?)

Zitat:

Zitat von Panthrax

Hm!?

siehe mein nacheditierter Link da oben

Delphi-Quellcode:

function generic(T: TTreeItem) MyFunc(A: T): T;
begin
  // do something with the tree item
end;  

// oder

function generic(T) Max(A, B: T): T;
begin
  if A < B then
    Result := B
  else
    Result := A;
end;

[Panthrax]

Zitat:

OK, das wäre auch eine Erklärung, wobei man sich da ja auch nach C# hätte richten können

Wer richtet sich schon nach C#??? Von Abguckern abgucken?

Ok, das "Hm!?" war missverständlich, was ich sagen wollte "Was ist mit dem hier!?" -- Ist gleichwertig:

Delphi-Quellcode:

class procedure TKlasse.DelphiProzedur<T>(const Value: T);
procedure FPCProzedur(T)(const Wert: T);

// Aufruf:

TKlasse.DelphiProzedur<Integer>(123);
FPCProzedur(Integer)(123);

Derzeit ist noch Achtung geboten mit generischen Methoden: QC#76074 Generic methods on non-generic classes place blue dots in the wrong unit

[ryLIX]

Ich muss noch ma was Fragen...
Die generische Liste bietet mir ja bei der ObjectList die möglichkeit auf TypeCasts zu verzichten.

Also sollte doch bei meiner TNonFoodList welche von TObecjtList<TNonFood> erbt folgender aufruf funktionieren:

Delphi-Quellcode:

var
  s: string;
begin
s:= locNonFoodList.Items[X].Artikelname;
end;

TNonFood enthält natürlich ein Feld welches Artikelname heißt.

Nur wird mir Artikelname im Code Editor rot unterstrichen aber er compilliert trotzdem...
Warum? :gruebel:

Und dann wollte ich mein CustomSort übernehmen und hab da gleich das nächste Problem ...

Delphi-Quellcode:

procedure TNonFoodList.Sortieren(SortBy: TNonFoodArtikelEnum);
begin
  NonFoodArtikelSortieren := SortBy;
  Self.Sort(TComparer<TNonFood>.Construct(
            function (Left, Right: TNonFood): Integer
            begin
              case NonFoodArtikelSortieren  of
                Artikelname: CompareText(Left.Artikelname, Right.Artikelname);
                Menge: CompareValue(Left.Menge, Right.Menge);
                Preis: CompareValue(Left.Preis, Right.Preis);
                Kosten: CompareValue(Left.Kosten, Right.Kosten);
              end;
            end));
end;

Markiert wird end));
Compilermeldung:

Zitat:

[DCC Fehler] WarenContainerGenerisch.pas(92): E2010 Inkompatible Typen: 'TComparison<Waren.TNonFood>' und 'Procedure'

[jbg]

Zitat:

Zitat von ryLIX

Nur wird mir Artikelname im Code Editor rot unterstrichen aber er compilliert trotzdem...
Warum? :gruebel:

Weil Embarcadero das Wort ErrorInsight falsch geschrieben hat. Es müsste eigentlich ErrorInside heißen :mrgreen:
Irgendein Vollpfosten beim damaligen Borland war der Meinung, dass man statt den Parser des Compilers einen neuen in C# geschriebenen Parser für ErrorInsight braucht. Und der ist nicht mal 90% Delphi-konform. Für ein ErrorInsight braucht man aber 100%, sonst kann man das ganze Feature wegschmeißen. Leider haben sie es von 2004 bis jetzt noch nicht hinbekommen, den ErrorInsight-Parser alle Sprachfeatures beizubringen. Generic-Klassen und vor allem Generic-Arrays werden von wenig bis gar nicht richtig erkannt. Überladene Methode in einer if-Abfrage (=> if FileAge(..) then) unterringelt er, da der Parser sich immer für die erste Deklaration entscheidet (die bei FileAge natürlich deprecated ist). Usw. Am besten schaltet man das Feature ab, wenn man mit Generics was macht.

[Khabarakh]

Zitat:

Zitat von ryLIX

Und dann wollte ich mein CustomSort übernehmen und hab da gleich das nächste Problem ...

Wäre zwar wirklich merkwürdig, aber... du hast vergessen, Result zuzuweisen, vielleicht stört er sich daran.

Zitat:

Zitat von implementation

Die ham sogar generische Routinen eingeführt - sowas hab ich noch nie gesehen

Haskells Type Classes ;) ? Sprachen mit Duck Typing müssen wir wohl gar nicht erst erwähnen :) .

Zitat:

Zitat von himitsu

OK, das wäre auch eine Erklärung, wobei man sich da ja auch nach C# hätte richten können
(oder kam das auch später?)

Java 2004, C# 2005, FPC 2007

Zitat:

Zitat von Panthrax

Wer richtet sich schon nach C#???

Nimm die Scheuklappen ab, es ist ein Geben und ein Nehmen.

[Panthrax]

Zitat:

Zitat von Khabarakh

Zitat:

Zitat von Panthrax

Wer richtet sich schon nach C#???

Nimm die Scheuklappen ab, es ist ein Geben und ein Nehmen.

Das sind keine Scheuklappen. Nur, was gibt es da schon zu holen? :mrgreen: Ehrlich...

[ryLIX]

Zitat:

Zitat von Khabarakh

Zitat:

Zitat von ryLIX

Und dann wollte ich mein CustomSort übernehmen und hab da gleich das nächste Problem ...

Wäre zwar wirklich merkwürdig, aber... du hast vergessen, Result zuzuweisen, vielleicht stört er sich daran.

Ich glaube dann würde die Compiler Fehlermeldung anders lauten bzw Sort nicht wie gewünscht sortieren.
Ich hab es noch einmal nach diesem Beispiel hier versucht:
http://delphi.about.com/od/delphitip...rt-generic.htm

Ändert aber nichts an der Fehlermeldung.
Seltsam ist das TList<>.Sort als Pararmeter "AComparer Void-Typ" erwartet.

Delphi-Quellcode:

procedure TList<T>.Sort(const AComparer: IComparer<T>);

Und bei

Delphi-Quellcode:

TComparer<T> = class(TInterfacedObject, IComparer<T>)

Wäre der von mir verwendete Aufruf korrekt:

Delphi-Quellcode:

function Construct(const Comparison: TComparison<T>): IComparer<T>;

Kann es sein das es ein Bug im Compiler ist? :gruebel:

Tante Edit:
Also ich hab mal das komplette Beispiel nach gebaut.
Da funktioniert es ohne Fehler.
Kann es sein das <T> in diesem Fall keine Klasse sein darf? :roteyes:

[ryLIX]

So jetzt hab ichs.
So geht des CustomSort:

Delphi-Quellcode:

type
  TNonFoodComparer = class (TComparer<TNonFood>)
    function Compare(const Left, Right: TNonFood): Integer; override;
  end;

...

{ TNonFoodComparer }

function TNonFoodComparer.Compare(const Left, Right: TNonFood): Integer;
begin
  case NonFoodArtikelSortieren  of
    Artikelname: Result := CompareText(Left.Artikelname, Right.Artikelname);
    Menge: Result := CompareValue(Left.Menge, Right.Menge);
    Preis: Result := CompareValue(Left.Preis, Right.Preis);
    Kosten: Result := CompareValue(Left.Kosten, Right.Kosten);
  end
end;

...

{ TNonFoodList }
procedure TNonFoodList.Sortieren(SortBy: TNonFoodArtikelEnum);
begin
  NonFoodArtikelSortieren := SortBy;
  Self.Sort(TNonFoodComparer.Default);
end;

Aber die Probleme gehen weiter... :(
Ich habe versucht den Bug den himitsu hier beschrieben hat zu beheben.

Delphi-Quellcode:

constructor TNonFoodList.Create(const AComparer: IComparer<T>;
  AOwnsObjects: Boolean);
begin
  inherited Create(AComparer, AOwnsObjects);
end;

Hier hab ich nun Undeklarierter Bezeichner: 'T'
:? so langsam nervts mich....

[Panthrax]

Was versuchtst Du denn zu beheben, wenn Du nur den geerbten Kontruktor aufrufst? Außerdem: Die Fehlermeldung erscheint ganz zu Recht -- T ist unbekannt. Du musst den Vergleich-Typ IComparer<T> schließen ("instantiieren"), an der Stelle handelt es sich nicht mehr um einen offenen Typ.

[Uwe Raabe]

Vielleicht so?

Delphi-Quellcode:

constructor TNonFoodList.Create(const AComparer: IComparer<TNonFood>; AOwnsObjects: Boolean);

Da TNonFoodList nicht mehr generisch ist, kann mann den Platzhalter T auch nicht mehr verwenden, sondern muss ihn durch einen bekannten Typ ersetzen.

[ryLIX]

Der Hinweis von Uwe hats gebracht. :thumb:

[himitsu]

Hey, warum ist eigenlich nie alles mal richtig vieles etwas versteckt dokumentiert?

Delphi-Quellcode:

Type
  TMyRecord<T> = Record
    X: T;
    Procedure Proc(P: T);
  End;
  TMyClass<T> = Class
    X: T;
    Procedure Proc(P: T);
  End;
  TMyInterfaceRecord<T> = Interface
    Procedure Proc(P: T);
  End;

Procedure MyProc<T>(P: T);
  Begin
  End;

Bis auf die Prozedur geht alles in Delphi. :shock:
zumindestens in Delphi 2010 ... anderes Versionen kann ich grade nicht testen.

[add]
In Delphi 2009 geht's auch und Turbo Delphi kennt noch keine Generics.

[Uwe Raabe]

Zitat:

Zitat von himitsu

zumindestens in Delphi 2010 ... anderes Versionen kann ich grade nicht testen.

Mist, ich kann mein Delphi 2011 im Moment auch gerade nicht finden...

[Panthrax]

Zitat:

Zitat von Uwe Raabe

Zitat:

Zitat von himitsu

zumindestens in Delphi 2010 ... anderes Versionen kann ich grade nicht testen.

Mist, ich kann mein Delphi 2011 im Moment auch gerade nicht finden...

Puuh,... und ich hatte schon Angst, nur mir geht es so...

Zitat:

Zitat von himitsu

Hey, warum ist eigenlich nie alles mal richtig dokumentiert?

Deklaration von Generics, oder Deklaration von Generics Ich weiß nicht, aber muss man auch dokumentieren, was nicht geht?

[himitsu]

Komisch mit ist so, als wenn ich sowas noch nie mit Records gesehn hatte.
(immer nur Klassen und Co.)