"to MI or not to MI"

[Xin]

Shade Of Mine schrieb:

Ha, so jetzt funktioniert es besser:
http://ideone.com/Wk2LNB

Ich kann jetzt

void verdoppleRadius(Radius& r) {
    r=r+r;
}

schreiben.

Und wenn man sich den ganzen Quellcode anschaut, der dafür in C++ nötig ist, versteht man sehr gut, warum kein normaler Mensch sich auch nur Gedanken darüber macht, ob man darauf aufbauend vielleicht etwas Praktisches erreichen kann.
Ja, schon klar, ich kann mir die Schlussfolgerung schon selbst denken... :->

Shade Of Mine schrieb:

PS:
Diese asFoo() funktion mag ich nicht, weil die nicht implizit aufgerufen wird. Wenn ich
r.asPositiveInteger().asInteger() aufrufen muss, komm ich mir irgendwie doof vor

Protected wird hier global über alles gelegt. Eigentlich müsste Integer unterscheiden, ob es als Objekt existiert und Zuweisungen von Außen zulässt oder ob es als Basisklasse für PositiveInteger() existiert. Da PositiveInteger() eigentlich eine Einschränkung der Menge gültiger Werte von Integer ist, ist nur der Teil von Operationen vererbbar, der einen Wert aus der gültigen Menge (den positiven Zahlen) nicht in einen ungültigen Wert verwandelt.

Man kann also alle const-Methoden direkt vererben (was man in C++ über operator Integer CONST &() impliziet ausdrücken könnte, wenn C++ es erlauben würde), den Zuweisungsoperator hingegen muss man in PositiveInteger reimplementieren.

Die operation - wäre also durchaus legitim: PositiveInteger( 1000 ) - PositiveInteger( 2000 ) ergibt ein Integer( -1000 ). Das wiederum könnte man über PositiveInteger::operator=( Integer const & ) zuweisen und hier prüfen, ob man diese Zuweisung das Objekt nicht in eine fehlerhaften Zustand überführt. Integer::operator=( Integer const & ) ist ja für PositiveInteger nicht sichtbar.

Die Ableitungsformel wäre also quasi "const public mutable protected".

[Shade Of Mine]

Ne, ich will das jetzt austesten - wenn es umständlich ist, dann ist es das halt. Das stört mich nicht.

Ich habe gerade aufgegeben PunktXY observable zu machen, weil das einfach zu kompliziert geworden wäre. Ich habe mit Radius ja schon ein observable Konstrukt.

http://ideone.com/5YY8an

Das Problem dass ich damit habe ist, dass jedes Implementationsdetail öffentlich ist. Es ist zB nicht möglich beim Ursprung des Kreises plötzlich auf double zu wechseln wenn ich vorher int verwendet habe. Oder zB auf __int64 statt __int32 oder sowas. Weil überall in meinem Clientcode eben direkt PunktXY verwendet wird. Und PunktXY kann ich ja nicht ändern, weil das von allen anderen Klassen auch verwendet wird.

Was cool ist, ist printKoordinaten. Das ist richtig cool. Aber das ist jetzt die einzige Situation wo ich was cooles gefunden habe.

Ich bin mir auch nicht ganz sicher über solche Sachen wie Radius=Laenge*PunktX/PunktY.

Mein Fazit: in C++ komme ich nichtmal zu der Stelle wo es interessant wird, weil die Sprache sich mit Händen und Füßen gegen diesen Ansatz wehrt.

Gibt es eine Sprache in der dein Ansatz verfolgbar ist? Du musst ja schon Erfahrung damit haben: hast du vielleicht Code wo du das Umgesetzt hast? Wie gesagt - Sprache ist mir egal. Aber in C++ kommen wir hier auf keinen Grünen Zweig.

[Xin]

Shade Of Mine schrieb:

Ne, ich will das jetzt austesten - wenn es umständlich ist, dann ist es das halt. Das stört mich nicht.

Blut geleckt? ^^

Shade Of Mine schrieb:

Das Problem dass ich damit habe ist, dass jedes Implementationsdetail öffentlich ist. Es ist zB nicht möglich beim Ursprung des Kreises plötzlich auf double zu wechseln wenn ich vorher int verwendet habe. Oder zB auf __int64 statt __int32 oder sowas. Weil überall in meinem Clientcode eben direkt PunktXY verwendet wird. Und PunktXY kann ich ja nicht ändern, weil das von allen anderen Klassen auch verwendet wird.

Hier kommen dann quasi Templates ins Spiel...

Shade Of Mine schrieb:

Was cool ist, ist printKoordinaten. Das ist richtig cool. Aber das ist jetzt die einzige Situation wo ich was cooles gefunden habe.

Immerhin.

Manchmal übersieht man aber Dinge, die nicht gefunden werden können, weil sie nicht da sind.
Ist Dir mal aufgefallen, dass Du Dir keine Membernamen ausdenkst?

Das finde ich richtig cool.

Shade Of Mine schrieb:

Gibt es eine Sprache in der dein Ansatz verfolgbar ist? Du musst ja schon Erfahrung damit haben: hast du vielleicht Code wo du das Umgesetzt hast? Wie gesagt - Sprache ist mir egal. Aber in C++ kommen wir hier auf keinen Grünen Zweig.

Ich kann mich nur selbst zitieren:

Xin schrieb:

Ich kann Dir nicht sagen, ob es dafür eine Sprache gibt, mir ist keine bekannt, sonst würde ich die ja verwenden und nicht selbst eine schreiben. ^^

Wobei... würde ich wohl doch... ich habe ja auch ein paar andere verrückte Ideen und Spaß macht's auch noch. ^^

[ipsec]

@Xin: gibt es vielleicht irgendwo ein Dokument oder irgendwas, was deine Sprache mal skizziert? Deine Ideen diesbezüglich interessieren mich wirklich (du hast ja Verschiedenes auch schon in anderen Threads angedeutet). Oder könntest du mal ein paar Grundgedanken andeuten? Was sind noch grundlegende Neuerungen gegenüber existierenden Sprachen? Das muss ja nicht ausformuliert sein, nur damit man mal einen Eindruck bekommt.
Und hast du dich mal mit funktionalen Sprachen beschäftigt? Offenbar betreibst du ja viele Gedanken in Richtung Sprachdesign und meines Erachtens haben funktionale Sprachen (z.B. Haskell) eine innewohnende Eleganz, die sowohl OOP als Konzept, als auch die mir bekannten imperativen und objektorientierten Sprachen nicht ansatzweise erreichen. Oder gibt es andere Gründe, warum deine Sprache objektorientiert/imperativ ist?

[Shade Of Mine]

Ich habe jetzt probiert eine Klasse Auto zu schreiben und puh. Jetzt eck ich nur noch an.

http://ideone.com/UDxDDd

Ich bekomme die Klasse Tank nicht so hin, dass sie von Fuellstand und Maximalstand erbt, aber diese Beiden Werte zueinander in beziehung setzt. So will ich, dass der Fuellstand nie unter 0 aber auch nie üeber Maximalstand geht.

Das ist aber alles doof, weil ja Auto ebenfalls zugriff auf Maximalstand und Fuellstand haben will. Auf herkömmliche Art ist das ganze ja trivial - aber hier artet das etwas aus.

Ich habe irgendwie das Gefühl dass das Open Closed Principle hier nicht so ganz passen will. Wenn ich Komponenten schreibe, dann sind die immer ziemlich genau auf meinen Usecase zugeschnitten. Ich muss zB Fuellstand von meinem ChangeObserver erben lassen noch bevor ich eine Klasse Tank habe. Was wenn ich später drauf komme ich will zB Geschwindigkeit ebenfalls Observen? Dann muss ich ja Geschwindigkeit ändern... Irgendwie muss da noch was besseres her.

Was auch total ärgerlich ist, ist dass die Werte die ich überall zuweise keinen Namen haben. Es ist immer Integer::value und nie PS oder kmh oder xCoord. Das macht den Code etwas doof zu warten.

Sobald ich nicht public erbe, habe ich Probleme. Solange ich alle Klassen immer public erben lassen läuft das ganze eigentlich relativ flüssig. Aber wenn ich Beschränkungen machen will, dann wird es tricky. Und Implementierungsdetails verstecken kann ich auch nicht. Auch Templates helfen mir da kaum weiter - weil ich vorher genau wissen muss was ich verstecken will und was nicht (ich kann nur ja nur wenige Details verstecken - über eine höhere Abstraktionsebene). Dadurch verliere ich aber wieder die "composability" also die Möglichkeit nach belieben die Komponenten zusammenzustöpseln.

Vielleicht habe ich heute Abend noch eine Erleuchtung aber bis jetzt sehe ich keinen Sinn.

Die ganze Zeit wünsche ich mir einfach nur Mixins - die lösen diese Probleme. Hast du dir schonmal Rubys Mixins oder zB JavaScripts prototype angesehen?

[Xin]

ipsec schrieb:

@Xin: gibt es vielleicht irgendwo ein Dokument oder irgendwas, was deine Sprache mal skizziert? Deine Ideen diesbezüglich interessieren mich wirklich (du hast ja Verschiedenes auch schon in anderen Threads angedeutet).

Es gibt solche Dokumente teilweise und ich übertrage sie wenn ich Zeit habe in ein dafür vorgesehenes Wiki. Da ich alleine daran arbeite, auch regelmäßig auf neue Ideen stoße, ist das aber alles nicht wirklich auf aktuellem Stand.
Für gute Doku fehlt mir leider die Zeit, was schade ist, denn falls ich mal unter die Bahn gerate, gibt's halt kein aktuelles Backup.

ipsec schrieb:

Oder könntest du mal ein paar Grundgedanken andeuten? Was sind noch grundlegende Neuerungen gegenüber existierenden Sprachen? Das muss ja nicht ausformuliert sein, nur damit man mal einen Eindruck bekommt.

Zwei Dinge: Erstens will ich eigentlich noch gar keinen öffentlichen Eindruck vermitteln und zweitens würde ich mich nicht soweit rauslehnen um von "grundlegenden Neuerungen" zu sprechen. Ich will nicht das Programmieren neu erfinden. Ich bin faul, ich will wenig Arbeit haben (jaja, ich weiß, klever dann eine Programmiersprache zu schreiben, um weniger programmieren zu müssen...) und ich will dass die Sprache mich gut unterstützt.

Zu Anfang habe ich Leute gesucht, die sich dafür begeistern konnten. Habe ich gefunden. Leider sind sie entweder nicht in der Lage zu helfen oder wissen, dass sie diese Zeit auch gegen Geld in andere Projekte stecken können. Dann habe ich vielversprechende und interessierte Leute in C++ unterrichtet. Die einen entwickelten andere Interessen, die anderen bemerkten, dass man Wissen auch teuer verkaufen kann und andere einfach besser zahlen können als ich. Kurz: der Aufwand andere zu involvieren kostet mich viel Zeit, ist aber nicht sonderlich produktiv bisher.

Ich habe da inzwischen viel eigene Zeit reingesteckt - in mein Projekt und in andere Leute. Die anderen Leute habe ich inzwischen aufgegeben, mein Projekt steckt jetzt in den Kinderschuhen und lernt gerade laufen.

ipsec schrieb:

Und hast du dich mal mit funktionalen Sprachen beschäftigt? Offenbar betreibst du ja viele Gedanken in Richtung Sprachdesign und meines Erachtens haben funktionale Sprachen (z.B. Haskell) eine innewohnende Eleganz, die sowohl OOP als Konzept, als auch die mir bekannten imperativen und objektorientierten Sprachen nicht ansatzweise erreichen. Oder gibt es andere Gründe, warum deine Sprache objektorientiert/imperativ ist?

Ich war mal eine Zeit recht fit in Prolog und vor laaaanger, laaaaaaaanger Zeit in einer LISP ähnlichen Sprache.

Ich denke, die Idee funktionaler Sprachen zu verstehen. Eine Garantie gebe ich darauf nicht.
Ich wollte mir letztes Jahr Scala aneignen, was leider an Zeitmangel auf dieses Jahr verschoben wurde. Haskell habe ich mir nur kurz angesehen, steht auch auf meiner Todo-Liste, aber deutlich weiter hinten. Mir sind die Vorteile von unveränderlichen Werten bei funktionalen Programmiersprachen bewusst.

Warum imperativ? Ich glaube nicht an die Einordnung in Paradigmen. Das Paradigma "OOP" ist nur ein Design-Pattern und funktionale Programmierung ist eigentlich nichts weiter als eine Sonderform von imperativer Programmierung, aufgrund der gewisse Grundannahmen getroffen werden können, die sich zur Optimierung eignen. Im Prinzip lässt sich das ganze auf imperative Programmierung zusammenschieben und die Programmierung, wie sie in C++/Java/C# getätigt wird, lässt sich ebenfalls deutlich reduzieren.

Immer wieder gerne gesehen sind Ausdrücke. Der Wunsch eines jeden (mir bekannten) Programmiersprachendesigners ist alles auf den Ausdruck zu reduzieren (gut, das sind nicht viele...). Mir sagt das auch zu, denn wenn alles ein Ausdruck ist, muss die Syntax einerseits sehr flexibel sein, andererseits erlaubt es kaum Ausnahmen.

Imperativ ist Einsteigern leicht zu vermitteln und praktisch für viele einfache Fälle. Funktional als Sonderform ist eher für Fortgeschrittene. Ich möchte nicht auf 'leicht vermittelbar' und 'praktisch für einfache Fälle' verzichten.

Shade Of Mine schrieb:

Ich habe jetzt probiert eine Klasse Auto zu schreiben und puh. Jetzt eck ich nur noch an.

Das wird ein langer Tag, ich komme hier heute zu nix... :->
Musst Du nicht auch zwischenzeitlich irgendwas für Geld tun?

Vielleicht wirfst Du die Kreise etc. auch mal weg oder lagerst sie zumindest aus.
Die Fehlermeldungen für operator+ sehen... merkwürdig aus. Sicher dass das Macro sauber ist?

Keine Ahnung, ob ich heute Abend noch in der Lage bin, den Quellcode auszuprobieren. Am liebsten würde ich da direkt mitspielen, aber diese Woche ist noch High-Life in Tüten. Keine Ahnung, wann ich heute überhaupt noch zu Hause eintreffe. Mann, Mann, Mann...

Shade Of Mine schrieb:

Ich bekomme die Klasse Tank nicht so hin, dass sie von Fuellstand und Maximalstand erbt, aber diese Beiden Werte zueinander in beziehung setzt. So will ich, dass der Fuellstand nie unter 0 aber auch nie üeber Maximalstand geht.

Das ist aber alles doof, weil ja Auto ebenfalls zugriff auf Maximalstand und Fuellstand haben will. Auf herkömmliche Art ist das ganze ja trivial - aber hier artet das etwas aus.

Das Auto hat doch Zugriff auf den Tank und der Tank hat einen Füllstand und einen Maximalstand!?

Shade Of Mine schrieb:

Ich habe irgendwie das Gefühl dass das Open Closed Principle hier nicht so ganz passen will. Wenn ich Komponenten schreibe, dann sind die immer ziemlich genau auf meinen Usecase zugeschnitten. Ich muss zB Fuellstand von meinem ChangeObserver erben lassen noch bevor ich eine Klasse Tank habe. Was wenn ich später drauf komme ich will zB Geschwindigkeit ebenfalls Observen? Dann muss ich ja Geschwindigkeit ändern... Irgendwie muss da noch was besseres her.

Ich kann jetzt nicht viel dazu sagen und für mal kurz ohne Compiler drüber zu gucken ist der Code etwas lang viel für meinen Bio-Stack.

Shade Of Mine schrieb:

Was auch total ärgerlich ist, ist dass die Werte die ich überall zuweise keinen Namen haben. Es ist immer Integer::value und nie PS oder kmh oder xCoord. Das macht den Code etwas doof zu warten.

Du hast Motor als PS definiert. Eigentlich hättest Du wie bei der Geschwindigkeit eine Klasse PS haben müssen, die dann in Motor übergeht, so dass Du zu

auto = PS(123);

kommst.

Shade Of Mine schrieb:

Sobald ich nicht public erbe, habe ich Probleme. Solange ich alle Klassen immer public erben lassen läuft das ganze eigentlich relativ flüssig. Aber wenn ich Beschränkungen machen will, dann wird es tricky.

Ich bin mir noch nicht ganz sicher, ob ich public const protected mutable sauber ausdrücken kann. Ich kann es mir im Kopf vorstellen, auf die Idee das in C++ zu formulieren, bin ich aber bisher nicht gekommen. Vielleicht aus Angst das gut zu finden und dann in die produktive Programmierung zu übernehmen, um Realworld-Erfahrungen damit zu sammeln. ;-D

Shade Of Mine schrieb:

Und Implementierungsdetails verstecken kann ich auch nicht. Auch Templates helfen mir da kaum weiter - weil ich vorher genau wissen muss was ich verstecken will und was nicht (ich kann nur ja nur wenige Details verstecken - über eine höhere Abstraktionsebene). Dadurch verliere ich aber wieder die "composability" also die Möglichkeit nach belieben die Komponenten zusammenzustöpseln.

Vielleicht habe ich heute Abend noch eine Erleuchtung aber bis jetzt sehe ich keinen Sinn.

Die ganze Zeit wünsche ich mir einfach nur Mixins - die lösen diese Probleme. Hast du dir schonmal Rubys Mixins oder zB JavaScripts prototype angesehen?

Ruby Mixins habe ich noch nicht angesehen. Ruby streitet sich mit ObjC um Platz 2 auf meiner Sprachen-Lern-Liste. Das Problem ist dann noch, wirklich Erfahrungen mit den Konstrukten zu sammeln, weil meine Projekte nunmal fast alle in C++ ablaufen und ich keine Zeit für zusätzliche erwähnenswerten Projekte hätte, wo man die große Erfahrung sammeln könnte.

JavaScript Prototypes habe ich mal vor längerer Zeit programmiert, da müsste ich aber nochmal nachgucken, da ich von JavaScript eher panisch abgeschreckt als inspiriert war. (Passend dazu)

[Shade Of Mine]

Ich habe den Ansatz komplett verworfen. Ich hab ihm heute jede freie Minute waehrend der Arbeit gegeben und muss leider sagen: ich komme nichtmal soweit, dass ich volkards Kritik an dem Ansatz bearbeiten kann. Ich scheitere vorher.

Der Code ist sicher schlecht und koennte 100mal besser gemacht werden. Aber das einzige was sich gut angefuehlt hat an dem Ansatz war, sagen zu koennen: Das Ding hat jetzt einen Namen und somit ein getName/setName.

Aber das ist mit Vererbung nicht gut ausgedrueckt. Mir ist alter Code eingefallen den ich vor langer langer Zeit mal geschrieben habe: Container Adapter.

Wenn ich einen vector habe und ich will den jetzt aber nur noch sortiert haben, auch wenn ich spaeter nochwas hinzufuege - wie tue ich das? Meine Loesung waren damals Adapter:

template<typename ContainerT>
class sorted_container_mutable :
	public interface_add_sorted_insert<
		interface_add_sequence_access<
			interface_base<
				ContainerT
			>
		>
	> {
};

template<typename ContainerT>
class sorted_container :
	public interface_add_sorted_insert<
		interface_add_const_sequence_access<
			interface_base<
				ContainerT
			>
		>
	> {
};

einmal sorted und einmal mutable_sorted.
Dazu natuerlich noch die ganzen Interface Operationen:
http://ideone.com/IvaTTL

Sowas fuehlt sich irgendwie besser an.
Genauso haette ich auch gerne Kreis nicht von PunktXY abgeleitet sondern nur einen Accessor zu PunktXY ueber Kreis drueber gelegt. Nur ist Vererbung hier nicht so toll. IMHO schreit der Ansatz nach Mixins.

Sowas sieht da etwas besser aus IMHO: http://ideone.com/sPY3Xs
Sofern man rausfindet wie man ctors sinnvoll vererben kann.
Sowas ist aber nur billiger Mixin Ersatz

Es gibt viele Sprachen die Mixins bieten. Ich persoenlich mag den JavaScript Ansatz - JavaScript hat natuerlich viele WTFs - keine Frage. Aber alles in allem ist es ne ordentliche Sprache. Aber du solltest dir das Konzept Mixin wirklich naeher ansehen, denn nachdem ich jetzt einige Stunden mit dem vererbungskonzept rumprobiert habe - und nichtmal weit genug gekommen bin um das Konzept als ganzes zu sehen, weil es schon im Ansatz voller Probleme ist - muss ich sagen: Mixins wuerden die meisten der Probleme sofort loesen.

[knivil]

Quellcode anschaut, der dafür in C++ nötig ist

Als ob das die Argumentation der Gegenseite war. Auch hat der ein oder andere Erfahrungen mit Objektsystemen anderer Sprachen gemacht.

Ich verstehe immer noch nicht, welches Problem geloest warden soll. Und wenn C++ zu grottig ist, dann nimm doch Lisp oder Scheme. Die koennen mehr.

[Shade Of Mine]

So.

Habe heute weiter rumprobiert.
Aber es funktioniert nicht. Ich stoße konstant auf Ärgerlichkeiten. Zu dem Problem ob ein Auto ein Motor ist oder einen hat, komme ich nichtmal.

Ich habe folgende Probleme mit dem Ansatz:

Keine Information Hiding. Jedes Implementierungsdetail ist öffentlich, was nachträgliche Änderungen sehr schwer macht. Denn jedes Implementierungsdetail steht ja im Typen drin

Programmierung gegen Implementationen und nicht gegen Interfaces. Ich kann einen Typen nicht einfach austauschen. Wenn ich zB feststelle, dass vector kein guter Typ ist, kann ich nicht list stattdessen verwenden ohne das an jeder Stelle im Code auszubessern. Da ich ja immer Vector::add() schreibe...

Massig Codeverdopplung. Das kann natürlich an C++ liegen, aber da ich keine Interfaces habe die ich nutzen kann und keine Information verstecken kann, muss ich viel Code doppelt schreiben.

Codeänderungen brechen enorm viel Code. Ich führe zB einen neuen Vater ein, und schon habe ich dessen Scope geerbt. Das macht in C++ riesen Probleme und man benutzt dauernd ::Integer statt Integer. Das würde eine bessere Sprache natürlich lösen.

Änderungen einer Entitity können andere Entities kaputt machen. Indem ich in einem Vater eine neue Funktion einführe, kann ich damit Clientcode brechen.

Es entstehen unheimlich viele Typen. Man muss konstant neue Typen erstellen um vernünftige Namen zu haben. Wenn ich
int alter;
sagen will, dann muss ich von Integer eine Klasse Alter erben und von dieser Erbe ich dann um mein "int alter;" zu bekommen. Ich habe also massig nur einmal verwendete Typen die den Namensraum beschmutzen. Da braucht man ein Sprachfeature ala "Person : public Integer as Alter" oder so.

Invarianten sind nur schwer garantierbar, da eine Entity nicht in sich geschlossen ist. Ich ertappe mich immer dabei geschlossene Entitäten zu schreiben - die dadurch aber nichtmehr die Vererbung erlauben um die es geht. Diesen Punkt kann man aber uU lösen wenn man eine bessere Sprache hat.

Invarianten würden sich ganz gut garantieren lassen, wenn wir access specifier des Vaters im Kind ändern könnten. Mir ist nur nicht klar wie man sowas implementieren könnte.

Es entstehen sehr komische Verwandschaften zwischen Typen die eigentlich nicht beabsichtig sind. Das ist manchmal ganz witzig, aber manchmal einfach nur "wierd".

Es fehlen Verwandschaften die eigentlich ganz praktisch wären. Da wir keine Interfaces haben gegen die wir implementieren, sind prinzipiell sehr ähnliche Typen oft garnicht miteinander verwandt. Das könnte man durch Java Interfaces wieder ausbessern, in C++ müsste man aber Templates nehmen und die funktionieren nicht, da sie sich nicht die richtigen Eltern aus dem Typ rausziehen können.

Templates verlieren ihre Coolness. wie im vorherigen Punkt beschrieben: Templates können sich nicht den korrekten Vater aus dem Kind herausziehen. Und wenn sie das nicht können, ist das Kind nutzlos für sie - da sie die Typ-specifier nicht hinzufügen können bei einem Zugriff.

Alles in allem funktioniert der Ansatz in C++ nicht. Und um ehrlich zu sein, er funktioniert in keiner mir bekannten Sprache. Man verletzt fast konstant essentielle Guidelines wie Open Closed Principle, Liskov Substitute Principle, Program against Interfaces not Implementations, Information Hiding, Encapsulation,... Ich weiß nicht ob das eine gute Idee ist.

Wenn man so radikal anders programmieren will, müsste man wohl von OOP weg. Aber ich meine Metasprachen gibt es ja schon. In JavaScript schreibt man sich idR Funktionen die dann Klassen erstellen die man dann instanziiert. dh ich kann mir gekapselte Komponenten schreiben und die dann beim erstellen einer Klasse darauf anwenden.

Ich sehe schon was der Hintergedanke von dir ist: Ich importiere mir die Komponenten die ich brauche und muss mich nicht mit der Implementierung beschäftigen. Ich sage einfach Auto holt sich alles von Motor was es braucht. Aber irgendwie ist da Vererbung die falsche Formulierung. In JavaScript würde ich folgendes schreiben:

var Auto = {};
Motor.applyTo(Auto);

var mercedes = new Auto();
mercedes.volltanken();

Wobei Motor hier sowohl private als auch public Felder in Auto hinzufügen kann und natürlich auch für Auto unsichtbare Felder.

[SideWinder]

Danke Shade, wobei du natürlich Zeit investiert hast die viele andere Personen auch schon investiert haben und die man Xin auch zusammensammeln hätte lassen können Aber, man kann sich wohl alles zusammensuchen was hier gefragt wird, dementsprechend

MfG SideWinder

[Antoras]

knivil schrieb:

Ich verstehe immer noch nicht, welches Problem geloest warden soll.

Ich bin auch ausgestiegen. Geht es noch immer darum, dass man anstelle von

auto.tank.volltanken()

einfach nur

auto.volltanken()

schreiben kann?