Generics und Vererbung

[Stevie]

Zitat von USchuster:

Zitat von himitsu:

<ET: TBasicEdge> geht halt nicht. Man kann nur sowas sagen, wie record oder class.
Auf eine bestimmte Klasse kann man (bescheuerter Weise) keinen Typen einschränken.

Das kann ich nicht nachvollziehen mit D2009, D2010 und XE.

Delphi-Quellcode:

program Project110;

{$APPTYPE CONSOLE}

type
  TFoo = class(TObject);

  TBar<T: TFoo> = class(TObject)
  end;

var
  B: TBar<TFoo>;
  B2: TBar<TObject>;//[DCC Error] Project110.dpr(13): E2515 Type parameter 'T' is not compatible with type 'TFoo'
begin
end.

Diesen Unfug erzählt Himitsu schon eine Weile lang und es stimmt einfach nicht. Das einzige, was vor XE(?) nicht ging (ka, welche QC Nummer), war, dass ein type constraint auf eine Klasse nicht den constructor constraint mit beinhaltete und demnach bei einem T.Create meckerte (oder sowas ähnliches)

[himitsu]

Haben die das in XE nun eingebaut?
Kann aber auch sein, daß ich in einen anderen Genericfehler reinlief, denn als ich sowas mal versuchte, ging es nicht.

[Khabarakh]

Wenn ich das richtig sehe, ist dein Problem, dass TBasicEdgeList<E, V, TDirectedEdge<E, V>> nicht von TBasicEdgeList<E, V, TBasicEdge<E, V>> abgeleitet ist, was in einer Sprache ohne Kovarianz wie Delphi auch vollkommen korrekt ist. Mit diesem Ansatz wirst du also an der Stelle ein wenig Typsicherheit aufgeben müssen, Delphis Typsystem erlaubt das einfach nicht.

Edit: Um die Sache mit der Kovarianz auszuführen: Gäbe es diese in Delphi, könntest du in der Basisklasse lesend auf die Liste zugreifen. Hineinschreiben wäre in keiner Sprache typsicher.

[Stevie]

Zitat von Khabarakh:

Wenn ich das richtig sehe, ist dein Problem, dass TBasicEdgeList<E, V, TDirectedEdge<E, V>> nicht von TBasicEdgeList<E, V, TBasicEdge<E, V>> abgeleitet ist, was in einer Sprache ohne Kovarianz wie Delphi auch vollkommen korrekt ist. Mit diesem Ansatz wirst du also an der Stelle ein wenig Typsicherheit aufgeben müssen, Delphis Typsystem erlaubt das einfach nicht.

Edit: Um die Sache mit der Kovarianz auszuführen: Gäbe es diese in Delphi, könntest du in der Basisklasse lesend auf die Liste zugreifen. Hineinschreiben wäre in keiner Sprache typsicher.

Wenn du weißt, dass es sich um Kovarianz handelt, kannst du mit einem Hardcast "nachhelfen".

Beispiel:

Delphi-Quellcode:

var
  list1: TList<TObject>;
  list2: TList<TPersistent>;
begin
  list1 := list2;  // <- E2010 Incompatible types: 'Generics.Collections.TList<System.TObject>' and 'Generics.Collections.TList<Classes.TPersistent>'

Laut der Definition sind diese beiden Listen aber kovariant.
Also kann ich ohne Probleme folgendes machen: list1 := TList<TObject>(list2);

[Khabarakh]

Zitat von Stevie:

Wenn du weißt, dass es sich um Kovarianz handelt, kannst du mit einem Hardcast "nachhelfen".

Ah, das ist natürlich eine Möglichkeit . Da bin ich zu sehr an Typsysteme ohne Hintertür gewöhnt .

Zitat von Stevie:

Laut der Definition sind diese beiden Listen aber kovariant.

Eben nicht. Dafür müssten alle Member der Klasse kovariant im Typparameter sein (dieser darf also nur als Rückgabetyp auftauchen), Add zum Beispiel ist aber kontravariant. Für typsichere Kovarianz müsste man sich wie gesagt auf eine Teilmenge von Membern beschränken; in .NET ist beispielsweise List<T> invariant, IEnumerable<out T> dagegen kovariant. Oder man hilft eben mit einem Hardcast nach und achtet selbst genau darauf, dass man nur diese Teilmenge benutzt .

[Stevie]

Zitat von Khabarakh:

Zitat von Stevie:

Laut der Definition sind diese beiden Listen aber kovariant.

Eben nicht. Dafür müssten alle Member der Klasse kovariant im Typparameter sein (dieser darf also nur als Rückgabetyp auftauchen), Add zum Beispiel ist aber kontravariant. Für typsichere Kovarianz müsste man sich wie gesagt auf eine Teilmenge von Membern beschränken; in .NET ist beispielsweise List<T> invariant, IEnumerable<out T> dagegen kovariant. Oder man hilft eben mit einem Hardcast nach und achtet selbst genau darauf, dass man nur diese Teilmenge benutzt .

Hasse Recht. Hab nicht an die Methoden gedacht, die nicht kovariant sind.