Von TObjectList<T> erben?

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