Braucht man Mehrfachvererbung

Shade Of Mine schrieb:

Wie gesagt ein
type Bar = { 
   methode : void -> void;
   weitereMethode : void -> void;
   undNocheine : void -> void;
} 

void call_all(Bar b) {
  b.methode();
  b.weitereMethode();
  b.undNochEine();
}

bar : Bar = Foo();
waere mir am liebsten.

Nur C++, Java und die meisten Sprachen bieten mir diese Moeglichkeit nicht. Was kann man also tun um das call_all dennoch zu bekommen?

Was soll das bitte sein? Soll call_all(Bar b) eine Funktion im Typ Bar sein?
Es ist doch nun mal so dass man zwei Dinge unterscheidet: Schnittstelle (also die Typinformation) und die Implementierung der Schnittstelle (also die konkrete Klasse). Java bietet dir halt die Möglichkeit, mit dem Java-Interface explizit nur den Typ zu spezifizieren. Klassen spezifizieren auch einen Typ, aber liefern auch direkt die Implementierung. Abstrakte Klassen sind eine Mischung aus reiner Schnittstellenspezifikation und Implementierung.

Was genau fehlt Dir daran? Was genau findest Du schlecht? Was genau möchtest Du besser machen?

.filmor

tfa schrieb:

Zu deinem serializable Vector Bespiel:
Wie würdest du mit Mehrfachvererbung folgendes lösen: Du hast Vektoren, die sich in einen
String serialisieren sollen, andere in XML oder in eine Binärform oder in eine Datenbank
(nenn es meinetwegen nicht serializable sondern persistable).
Hast du dann 1000 Vektor-Klassen wie StringSerializableVector, XMLSerializableVector, BinarySerializableVector, SqlSerializableVector, SqlOracleSerializableVector, SqlOracleVersion8SerializableVector, usw.?? Wenn du jetzt noch ein Set und eine Map
mit den gleichen serializable-Funktionalitäten haben willst, dann multipliziert sich die Anzahl Klassen nochmal.

Selbstverständlich wäre die zu implementierende serialize-Methode unabhängig von der Art der Ein- bzw. Ausgabe. Daher reicht es, von Serializable abzuleiten.
Sowas muss doch auch in Java machbar sein.

tfa

.filmor schrieb:

Sowas muss doch auch in Java machbar sein.

Ist es, wie schon mehrfach angesprochen. Nur eben nicht überImplementationsvererbung druch Mehrfachvererbung.

Shade Of Mine

byto wech schrieb:

Was genau fehlt Dir daran? Was genau findest Du schlecht? Was genau möchtest Du besser machen?

Die unimplementierbarkeit von call_all().

Es ist einfach nicht möglich das in Java zu machen.

Der beste Ansatz wäre, freistehende Funktionen zu haben die das Verhalten definieren. Dazu müsste man aber weggehen von dem Klassenkonzept. Dann hätte man eine Menge Probleme nicht und diese ganze Diskussion hier wäre unnötig.

Aber wir haben Klassen und müssen damit leben. Klassen sind furchtbar einnengend. Und Java Interfaces engen noch mehr ein. Die Idee einer reinen minimalen Schnittstelle ist ja nicht schlecht, nur in Sprachen wie Java und C++ nicht verwendbar.

Man braucht sich nur Serializable ansehen. Es ist in Java nicht ohne Hack implementierbar. Das muss einem doch zu denken geben, oder?

.filmor

tfa schrieb:

.filmor schrieb:

Sowas muss doch auch in Java machbar sein.

Ist es, wie schon mehrfach angesprochen. Nur eben nicht überImplementationsvererbung druch Mehrfachvererbung.

Hab ich dich nur falsch verstanden oder hast du es tatsächlich geschafft, eine Zeile eines aus zwei Zeilen bestehenden Posts ihres Kontextes zu berauben?

Mir ging es darum, dass es auch in Java machbar sein muss, dass serialize unabhängig von der Art der Serialisierung (String, XML, was auch immer) nur einmal implementiert wird.

Braucht man Mehrfachvererbung?

Definitiv Nein

Shade Of Mine schrieb:

Man braucht sich nur Serializable ansehen. Es ist in Java nicht ohne Hack implementierbar. Das muss einem doch zu denken geben, oder?

Das behauptest du jetzt schon zum zweiten mal, dann verrate doch mal bitte wo du einen Hack brauchst um in Java Serializable zu implementieren. Was kannst du den nicht machen? Wo schränken dich da die Java Interfaces ein?

Shade Of Mine

wathacks schrieb:

Shade Of Mine schrieb:

Man braucht sich nur Serializable ansehen. Es ist in Java nicht ohne Hack implementierbar. Das muss einem doch zu denken geben, oder?

Das behauptest du jetzt schon zum zweiten mal, dann verrate doch mal bitte wo du einen Hack brauchst um in Java Serializable zu implementieren. Was kannst du den nicht machen? Wo schränken dich da die Java Interfaces ein?

Das ist ein Scherz oder?
Schau dir mal an wie writeObject und readObject integriert wurden.

Die JVM hat eine extra spezialbehandlung eingeführt. Etwas dass Clientcode nicht machen kann. Die Benutzung ist zwar super einfach - aber die Technik dahinter - eben _wegen_ den Java Interfaces ein Horror.

Shade Of Mine schrieb:

Das ist ein Scherz oder?

Du hast es immer noch nicht kapiert, oder?

Shade Of Mine schrieb:

wathacks schrieb:

Shade Of Mine schrieb:

Man braucht sich nur Serializable ansehen. Es ist in Java nicht ohne Hack implementierbar. Das muss einem doch zu denken geben, oder?

Das behauptest du jetzt schon zum zweiten mal, dann verrate doch mal bitte wo du einen Hack brauchst um in Java Serializable zu implementieren. Was kannst du den nicht machen? Wo schränken dich da die Java Interfaces ein?

Das ist ein Scherz oder?
Schau dir mal an wie writeObject und readObject integriert wurden.

Die JVM hat eine extra spezialbehandlung eingeführt. Etwas dass Clientcode nicht machen kann. Die Benutzung ist zwar super einfach - aber die Technik dahinter - eben _wegen_ den Java Interfaces ein Horror.

Wieso wegen den Java Interfaces? Das man ein paar Hacks brauch, um auf private member beliebiger Klassen zugreifen zu können ist klar. Aber was hat das mit den Interfaces zu tun? Wenn du das ohne diese Tricks machen willst, dann musst du halt ein Interface mit write... und read... machen und in jeder Klasse die das implementiert müssen dann die member per hand in den stream gesteckt werden. Ist dann nicht mehr so komfortabel, aber geht eigentlich ganz einfach mit den Java Interfaces. Oder was stellst du dir für eine Interface definition vor mit der das irgendwie anders geht?