Generische Ableitung einer Klasse

[s.h.a.r.k]

Hallo zusammen,

wollte gerade sowas hier schreiben, nur leider klappt das nicht:

Delphi-Quellcode:

TThreadedObject<T: class> = class(T)

end;

Der Cursor bleibt hinter dem T bei

Delphi-Quellcode:

class(T)

stehen und der Compiler meldet:

Code:

[DCC Fehler] ApCore.Classes.pas(68): E2021 Klassentyp erwartet

Weiß jemand warum das so ist?

Ziel des ganzen ist es einer beliebigen Klasse eine CriticalSection samt Lock/Unlock-Methoden zu spendieren, ohne da jetzt jedes erst von der Klasse ableiten zu müssen und den kompletten Code immer wieder zu schreiben.

[Neutral General]

Wie wäre es mit

Delphi-Quellcode:

TThreadedObject<T: class> = class

end;

? o.O

Edit: Achso.. du meinst das anders.. Ne.. das geht nicht..

[s.h.a.r.k]

Und warum nicht? :stupid:

[Neutral General]

Wie soll man die Klasse denn programmieren?

Du kannst keine Methoden überschreiben, du weißt nicht welche Methoden/Properties/Variablen dir zur Verfügung stehen.. Du weißt gar nichts. Wie willst du denn auf dieser Grundlage eine Klasse ableiten/implementieren?

[uligerhardt]

Zitat:

Zitat von Neutral General (Beitrag 1110081)

Du kannst keine Methoden überschreiben, du weißt nicht welche Methoden/Properties/Variablen dir zur Verfügung stehen.. Du weißt gar nichts. Wie willst du denn auf dieser Grundlage eine Klasse ableiten/implementieren?

Will/braucht er ja auch nicht:

Zitat:

Zitat von s.h.a.r.k (Beitrag 1110074)

Ziel des ganzen ist es einer beliebigen Klasse eine CriticalSection samt Lock/Unlock-Methoden zu spendieren, ohne da jetzt jedes erst von der Klasse ableiten zu müssen und den kompletten Code immer wieder zu schreiben.

[Neutral General]

Das hat doch nichts damit zu tun was er will oder braucht :roll:

Der Ansatz an sich macht (OOP-technisch) keinen Sinn.

Für sowas sind Class-Helper gedacht.

[uligerhardt]

Zitat:

Zitat von Neutral General (Beitrag 1110089)

Das hat doch nichts damit zu tun was er will oder braucht :roll:

Womit denn sonst? :?:

Zitat:

Zitat von Neutral General (Beitrag 1110089)

Der Ansatz an sich macht (OOP-technisch) keinen Sinn.

Sinnvoll ist der Ansatz schon, ob's jetzt OOP oder sonstwas für ein Paradigma ist. Statt z.B. eine

Delphi-Quellcode:

TThreadedObject<TStringList>

zu nutzen könnte man natürlich auch eine

Delphi-Quellcode:

TThreadedStringList = class(TStringList)

schreiben. Deren Implementation wäre aber bis auf den Namen der Basisklasse identisch mit TThreadedBlubb, TThreadedBlah und TThreadedSchlock. Das schreit doch nach Generics.

Zitat:

Zitat von Neutral General (Beitrag 1110089)

Für sowas sind Class-Helper gedacht.

Die waren dafür gedacht, dass man Delphis TObject in .net reinhämmern kann, sonst für nix. :mrgreen: Und im konkreten Fall bringen sie AFAIK eh nix, weil der OP ja Felder zur Basisklasse hinzufügen will.

[Neutral General]

Zitat:

Zitat von uligerhardt (Beitrag 1110093)

Zitat:

Zitat von Neutral General (Beitrag 1110089)

Das hat doch nichts damit zu tun was er will oder braucht :roll:

Womit denn sonst? :?:

Er WILL das vllt. nicht. Aber prinzipiell ist der Sinn einer Ableitung eine bestehende Klasse zu ERWEITERN. Das ist aber aus folgenden Gründen NICHT möglich:

Zitat:

Du kannst keine Methoden überschreiben, du weißt nicht welche Methoden/Properties/Variablen dir zur Verfügung stehen.. Du weißt gar nichts. Wie willst du denn auf dieser Grundlage eine Klasse ableiten/implementieren?

D.h. es wird voraussichtlich niemals einen Compiler geben, der sowas zulässt.
:arrow: Es macht keinen Unterschied ob er es will/braucht, wenn es einfach nicht geht.

Zitat:

Zitat von uligerhardt (Beitrag 1110093)

Zitat:

Zitat von Neutral General (Beitrag 1110089)

Der Ansatz an sich macht (OOP-technisch) keinen Sinn.

Sinnvoll ist der Ansatz schon, ob's jetzt OOP oder sonstwas für ein Paradigma ist. Statt z.B. eine

Delphi-Quellcode:

TThreadedObject<TStringList>

zu nutzen könnte man natürlich auch eine

Delphi-Quellcode:

TThreadedStringList = class(TStringList)

schreiben. Deren Implementation wäre aber bis auf den Namen der Basisklasse identisch mit TThreadedBlubb, TThreadedBlah und TThreadedSchlock. Das schreit doch nach Generics.

Die Grundidee ist gut. Der Ansatz das auf diese Weise mit Generics zu lösen ist schlecht, nicht machbar und OOP-technischer Schwachsinn.

Sowas wie TThreadedObject<TStringList> ist ja durchaus machbar und gut!

TThreadedBlubb, TThreadedBlah und TThreadedSchlock wäre natürlich noch ein Stück schöner, aber das schreit absolut nicht nach Generics. Für sowas sind und waren Generics nicht gedacht und es ist letztendlich einfach nicht machbar.

Zitat:

Zitat von uligerhardt (Beitrag 1110093)

Zitat:

Zitat von Neutral General (Beitrag 1110089)

Für sowas sind Class-Helper gedacht.

Die waren dafür gedacht, dass man Delphis TObject in .net reinhämmern kann, sonst für nix. :mrgreen: Und im konkreten Fall bringen sie AFAIK eh nix, weil der OP ja Felder zur Basisklasse hinzufügen will.

Aha..
Class-Helper gehen natürlich nur wenn er keine Felder hinzufügen muss. Die Dinger sind aber in manchen Situationen durchaus nützlich.

Wenns für ihn mit Class-Helpern nicht geht, dann bleibt ihm nur die TThreadedObject<TStringList> Variante oder er muss von jeder Klasse in der er Critical-Sections einbauen will ableiten.

[uligerhardt]

Zitat:

Zitat von Neutral General (Beitrag 1110099)

D.h. es wird voraussichtlich niemals einen Compiler geben, der sowas zulässt.

Ich hab mal den guten alten BCC55 und meine eingerosteten C++-Kenntnisse rausgekramt und folgendes produziert:

Code:

#include <iostream>
#include <string>

class MyClass
{
public:
  int blubb;
};

class YourClass
{
public:
  std::string blah;
};

template <typename T>
class TThreadedObject: public T
{
public:
  TThreadedObject() { std::cout << "lock" << std::endl; };
  ~TThreadedObject() { std::cout << "unlock" << std::endl; };
};

int main()
{
  TThreadedObject<MyClass> tb;
  TThreadedObject<YourClass> ty;
  tb.blubb = 42;
  ty.blah = "Hallo";
  std::cout << tb.blubb << std::endl;
  std::cout << ty.blah << std::endl;
}

Das lässt sich compilieren, läuft und spuckt erwartungsgemäß

Code:

lock
lock
42
Hallo
unlock
unlock

aus. Ich denke, das ist vom Prinzip her, das was der OP gerne hätte. So eine Art Mixin.

[s.h.a.r.k]

Hm, okay... Habe nun wohl langsam verstanden, warum ich das nicht machen kann bzw. der Compiler sich bei sowas quer stellt. Interessant wäre es aber trotzdem gewesen.

Class Helpers können wahrlich ganz schön sein, aber kann man das hier überhaupt anwendbar? Habe noch nie versucht neue Felder einzuführen -- wurde ja erwähnt, dass dies nicht möglich sei.