Generische Ableitung einer Klasse

[Neutral General]

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

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

Für sowas sind Class-Helper gedacht.

[uligerhardt]

Zitat von Neutral General:

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

Womit denn sonst?

Zitat von Neutral General:

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 TThreadedObject<TStringList> zu nutzen könnte man natürlich auch eine 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 von Neutral General:

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. Und im konkreten Fall bringen sie AFAIK eh nix, weil der OP ja Felder zur Basisklasse hinzufügen will.

[Neutral General]

Zitat von uligerhardt:

Zitat von Neutral General:

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

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.
Es macht keinen Unterschied ob er es will/braucht, wenn es einfach nicht geht.

Zitat von uligerhardt:

Zitat von Neutral General:

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 TThreadedObject<TStringList> zu nutzen könnte man natürlich auch eine 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 von uligerhardt:

Zitat von Neutral General:

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. 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 von Neutral General:

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.

[Stevie]

Ein Template, wie Uli es gebaut hat, geht auch ohne weiteres in Delphi. Das hat aber noch lange nix mit Generics zu tun, nur weil Generics mithilfe von Templates implementiert sind.Diese Frage gab es auch mal bei Stack Overflow.

[BUG]

Ich hätte noch ne schmutzige Variante:

Man könnte doch über ein Map (zB eine Hashmap) Objektzeigern eine Critical Section zuordnen und dann lock und unlock doch über Class Helper einführen (Die Map sollte dann ihre eigene Critical Section haben bzw. Thread-safe sein.)

[s.h.a.r.k]

@BUG: Die Idee hatte ich auch schon. Allerdings wird es dann dahingehend unschön, dass das mit der Freigabe dann so eine Sache wird. Wobei... eigentlich könnte man sowas schon machen, aber es werden am laufenden Band CriticalSections erzeugt, was dann wiederrum nicht so schön ist. Ich glaube ich bleibe bei meinen einzelnen Ableitungen

[QuickAndDirty]

Habe selbst maximal D2007 (auf einem anderen Arbeitsplatz) gibt es mittlerweile in fortschrittlicheren Delphiversionen so perverses zeug wie "Aspekte"? Und wäre das dann eine Lösung ?

[Neutral General]

Zitat von QuickAndDirty:

Habe selbst maximal D2007 (auf einem anderen Arbeitsplatz) gibt es mittlerweile in fortschrittlicheren Delphiversionen so perverses zeug wie "Aspekte"? Und wäre das dann eine Lösung ?

Sowas gibts in Delphi Prism soweit ich weiß. Im "normalen" Delphi gibt es sowas bisher nicht.